Groovy GPars, как заснуть поток по номеру потока / количество? - PullRequest
0 голосов
/ 10 июля 2011

У меня сейчас проблема с GPars, я хотел бы запустить около 30 потоков, но я хочу подождать 1 секунду после каждого запуска потока.

Мой код в настоящее время выглядит примерно так (Groovy / Grails):

withPool(30) {    // <= thread pool size
   Mail.findAllByStatus("new").eachWithIndexParallel { mail, i ->    // <= finds about 5000 mails
      sleep(i*1000)
      def doSomething = new Test()
      doSomething.do(mail) // <= runs for about 60sec
   }
}

Проблема в этом решении заключается в том, что "eachWithIndexParallel" запускает все потоки в случайном порядке одновременно, например, с 5000 писем:
начальный поток 3500 = ожидание 3500 секунд
запуск потока 1000= ждать 1000 секунд
.... пока не начнутся 30 потоков, тогда он будет ждать остановки потоков

И мне нужно решение, подобное этому:
запуск потока 2500 = ожидание 1 сек
запуск потока 5 = ожидание 2 с
запуск потока 4888 = ожидание 3 с
... до тех пор, пока не будет запущено 30 потоков, он ожидает остановки потоков

Если я просто использую переменную count, то яу меня проблема в том, что потоки умножения имеют одно и то же число из-за одновременного запуска ... и очень важно, чтобы у меня была задержка в 1 сек между каждым потоком.

Каки я решаю эту проблему?

Ответы [ 2 ]

1 голос
/ 10 июля 2011

Хммм, я не эксперт по GPars, но я не думаю, что это проблема GPars. Как насчет создания синхронизированной функции, которую все потоки вызывают, чтобы узнать их задержку?

private static delaycount = 1;
public synchronized int getMyDelay() {
   return delaycount++;
}

И измените свой код на:

int mydelay = getMyDelay()
sleep(mydelay*1000)
def doSomething = new Test()
doSomething.do(mail) // <= runs for about 60sec

внутри Mail.find ....

0 голосов
/ 10 июля 2011

или использование атомных целых чисел

определенно, если задержка важна, не полагайтесь на значение индекса, i, которое действительно должно использоваться при перечислении потоков

i такжене думайте, что 30 потоков остановятся и будут ждать друг друга, новые потоки будут порождаться до тех пор, пока n <30, </p>

, это, вероятно, сводит на нет преимущества наличия 30 потоков с задержками 1 ... 30 с

для принудительного выполнения этого в любом случае вам может потребоваться очередь, которая будет содержать следующую требуемую задержку, так что какой бы поток ни выполнялся, он извлечет задержку x из неиспользуемых чисел в 1..30

...