Использование QWaitCondition

[kuzulis]

Кстати, помнится мне, что уже было на форуме аналогичное обсуждение.

[Igors]

to Igors:
Но ведь wakeAll тогда в любом случае может "пропустить" цикл. Как от этого избавиться?

PS в любом случае, я так понимаю, если в ожидающем цикле будут действия после unlock, это приведёт как раз к возможному пропуску wakeAll(). так ведь?

update:
В том то всё и дело, что в любом случае после unlock у нас получается участок времени (пусть пренебрежительно малый, но всё же), во время которого наш wakeAll умрёт и в очереди останется необработанная часть данных.

И даже несколько потоков не дадут 100% гарантии в покрытии этого места.

Ну что сказать - молодец, думает пацан, а не так себе, букварь всасывает (ой перехвалю  )

Бояться пропуска wake не следует, в этом случае нас спасает счетчик данных. Если данные уже есть - извлекаем и обрабатываем, и только если нет - вызываем wait. Отсюда следует что WaitCondition ВСЕГДА используется со счетчиком, без него вся схема разваливается

Ладно, а слабо найти пробой в ассыстенте? (пример QWaitCondition)

[Bepec]

Хвалить полезно, принимать хвалу опасно

Попробую разобраться завтра.

А так конечно да. Счётчик vs Wait на взгляд помогают решить эту проблему. Надо самому попробовать.

[Авварон]

Я конечно понимаю, что обсирать кутешную доку - любимое дело Igors'а, но, если бы кто-то удосужился в нее заглянуть, то сразу после некорректного примера написано

Also, if some of the threads are still in do_something() when the key is pressed, they won't be woken up (since they're not waiting on the condition variable) and so the task will not be performed for that key press. This issue can be solved using a counter and a QMutex to guard it.

После чего идёт пример со счётчиком (в него уже не вникал, ибо лень; но факт в том, что он есть).

[Igors]

Я конечно понимаю, что обсирать кутешную доку - любимое дело Igors'а, но, если бы кто-то удосужился в нее заглянуть,

Аккуратнее пожалуйста, грубость и высокомерие Вас не украшают

После чего идёт пример со счётчиком (в него уже не вникал, ибо лень; но факт в том, что он есть).

О нем и речь

[Bepec]

Пожалуй меня в недоумение ввёл сон на 1 мс. Да и вызов wakeAll с залоченным мутексом.

А так - вроде нормально.

[Igors]

Пожалуй меня в недоумение ввёл сон на 1 мс. Да и вызов wakeAll с залоченным мутексом.

А так - вроде нормально.

Давайте для начала Вы приведете полный текст примера чтобы всем было однозначно ясно о чем речь. 

[Bepec]

Код:

// thread worker
     forever {
     mutex.lock();
     keyPressed.wait(&mutex);
     ++count;
     mutex.unlock();

     do_something();

     mutex.lock();
     --count;
     mutex.unlock();
 }

//control thread
     forever {
     getchar();

     mutex.lock();
     // Sleep until there are no busy worker threads
     while (count > 0) {
         mutex.unlock();
         sleep(1);
         mutex.lock();
     }
     keyPressed.wakeAll();
     mutex.unlock();
 }

[Авварон]

Аккуратнее пожалуйста, грубость и высокомерие Вас не украшают

Да нет, просто я регулярно (а точнее только их) вижу посты, содерщащие слова "писать по букварю", "обезьянки в ассистанте". Напрягает, если честно.

Тема хорошая и полезная (благодаря ей нашел у себя багу), однако постановка раздражает.

[Bepec]

По теме, господа, по теме.

[Igors]

Да нет, просто я регулярно (а точнее только их) вижу посты, содерщащие слова "писать по букварю", "обезьянки в ассистанте". Напрягает, если честно.

Насчет "обезьянок" - покажите где я такое допустил, извинюсь немедленно. Мне легко говорить - потому что не было такого "Букварь" - да, я говорю это часто, и что в этом плохого? Это базовая документация которую надо учить - в любой системе. Да, сначала надо "сделать по букварю" - может и проблем не возникнет.

На мой взгляд, беда в том что Qt букварь... слишком хорош, и это плохо (как бы "крайности сходятся"). Люди получают готовые, 100% разжеванные решения и.. моментально к этому привыкают. Какая там "удочка" если вокруг полным-полно вкуснейшей, жирнючей "рыбы" - хватило бы сил сожрать. Или не так? 

Тема хорошая и полезная (благодаря ей нашел у себя багу), однако постановка раздражает.

Ничего, переживете. А лучше подключайтесь-ка к изучению примера (см ниже) - там есть о чем поговорить, мне тоже далеко не все ясно/однозначно

----------

Верес, спасибо за copy/paste (ну просто здесь так надо). С чего начнем? Почему нужен sleep? Или где должен быть wake (внутри или снаружи захвата мутекса). Или где еще ошибка? Керуйте 

[Bepec]

Зачем нужен слип в принципе понятно.
Непонятно зачем блочить мутекс каждый раз в while. И эти постоянные локи унлоки настораживают. (и помоему они подтормаживать должны?)

По видимому вполне возможна ситуация deadlock'a (или меня вводит в заблуждение отсутствие условия вызовов)

Код:

 while (count > 0) {
// тут      
         mutex.unlock();
         sleep(1);
         mutex.lock();
// тут
     }

Хотя если потумкать и если вызываются слоты в разных потоках, тогда код на вид нормальный.

Код:

// thread worker
     forever {
     mutex.lock();
     keyPressed.wait(&mutex);     //ждём wake
     ++count;
     mutex.unlock();

     do_something();

     mutex.lock();
     --count;
     mutex.unlock();
 }
                                             
//control thread
     forever {
     getchar();                          // а тут ждём нажатия чела для последующей итерации

     mutex.lock();
     // Sleep until there are no busy worker threads
                                             
     while (count > 0) {              //если есть работающие потоки, тогда даём им захватывать мутекс и закончить обработку.
         mutex.unlock();
         sleep(1);
         mutex.lock();
     }
                                             
     keyPressed.wakeAll();           // пробуждаем потоки все, они просыпаются и ждут освобождения мутекса (или крах если с одного потока)
     mutex.unlock();                   // а тут уже даём им старт
     }

[Igors]

Зачем нужен слип в принципе понятно.
Непонятно зачем блочить мутекс каждый раз в while. И эти постоянные локи унлоки настораживают. (и помоему они подтормаживать должны?)

По видимому вполне возможна ситуация deadlock'a (или меня вводит в заблуждение отсутствие условия вызовов)

Код:

 while (count > 0) {
// тут      
         mutex.unlock();
         sleep(1);
         mutex.lock();
// тут
     }

Подтормаживать еще как должны - а что делать? Ведь здесь очереди-то нет (контейнера), приходится ждать пока обработчик "просрется" (навеяно предыдущим докладчиком). А просто так сделать sleep не катит - ведь мутекс захвачен нами, и обработчик не сработает до тех пор пока не освободим. Приходится сначала освобождать, ждать, потом опять захватывать. Вообще ихний пример как бы "наоборот" - показывает не силу а слабость примитива WaitCondition (ну вот, меня опять обвинят в нелояльности). Но базовый примитив на то и базовый - работать должно. Deadlock - откуда? Я захватил мутекс, я и освобождаю, никаких условий не использую 

Хотя если потумкать и если вызываются слоты в разных потоках, тогда код на вид нормальный.

"One thing at a time" как говорят буржуины. Или, по-нашему, "не гоните лошадей". Вот если все ясно почему sleep - тогда поехали дальше.

[Bepec]

Деадлок будет, если управляющий и работающий потоки окажутся в одной нити.

[Igors]

Ладно, пошли дальше.

Код:

// thread worker
     forever {
     mutex.lock();
     keyPressed.wait(&mutex);     //ждём wake
     ++count;
...

Да, счетчик вроде есть, но он используется уже после wait. Это не может работать правильно, в какой-то момент цикл обработки будет пропущен. Укажите как это происходит - или докажите что такое невозможно (и я не прав)