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

[Old]

Мотивировка типа: без захвата не запрещено, но смысла не имеет. Почему не имеет? Не понимаю куда смысл пропал?  

Понимаю, что "всех" вы сразу вспомнить не смогли.
Не слушайте "всех", читайте документацию. Там все четко написано, как нужно.

[Igors]

Ну вот я просто переставил 2 строчки

Код

C++ (Qt)
for (int i = 0; i < dataSize; i++)
{
	mutex.lock();					// Блокирем мютекс
 	while (listTask.size() == bufSize)		// Если буфер полный
		 bufNotFull.wait(&mutex);		// Ждем побудки буфер не полный
 
	listTask.push_back(i);				// Генерируем задачу
 
// 	bufNotEmpty.wakeAll();			// Побудка что буфер не пустой
 	mutex.unlock();					// Разблокируем мютекс
	bufNotEmpty.wakeAll();			// <----
}

Не вижу чем мне это грозит. Каким образом заклинит?

[Kosmonit]

Ну вот я просто переставил 2 строчки

Код

C++ (Qt)
for (int i = 0; i < dataSize; i++)
{
	mutex.lock();					// Блокирем мютекс
 	while (listTask.size() == bufSize)		// Если буфер полный
		 bufNotFull.wait(&mutex);		// Ждем побудки буфер не полный
 
	listTask.push_back(i);				// Генерируем задачу
 
// 	bufNotEmpty.wakeAll();			// Побудка что буфер не пустой
 	mutex.unlock();					// Разблокируем мютекс
	bufNotEmpty.wakeAll();			// <----
}

Не вижу чем мне это грозит. Каким образом заклинит?

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

[Igors]

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

Я тоже, в конце концов когда-то надо "просто запомнить". Но привести пример когда рухнет если wait не под мутексом - я не могу. Примерчик сделал - работает, но это ничего не доказывает

[Old]

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

Зависит от реализации.
Вот для pthread четко прописано, будить при захваченом мьютексе. Возможно, где то будет подругому, хотя я сильно сомневаюсь.
Сейчас мы по сути пытаемся использовать разделяемый ресурс (условную переменную) без защиты мьютексом. Что может произойти, если две нитки полезут в wake, зависит от реализации этого самого wake.

[Igors]

Вот для pthread четко прописано, будить при захваченом мьютексе.

Не вижу этой четкости, напр
http://stackoverflow.com/questions/4544234/calling-pthread-cond-signal-without-locking-mutex
Доказательство там очень неубедительное

[Old]

Аааааа. Вы бы еще ссылку на Хабр выложили.

[Igors]

Аааааа. Вы бы еще ссылку на Хабр выложили.

По-моему stackoverflow - очень толковый сайт. Ну и никто не мешает Вам привести действительно авторитетный (по Вашему мнению) первоисточник, а еще лучше - сценарий краша "по ходам".

[Old]

По-моему stackoverflow - очень толковый сайт.

Почему вы тогда не верите написанному там?

Ну и никто не мешает Вам привести действительно авторитетный (по Вашему мнению) первоисточник.

man pthread_cond_signal

а еще лучше - сценарий краша "по ходам".

А еще лучше!

[Igors]

Почему вы тогда не верите написанному там?

Так а что ж там написано

Process B (incorrect):

condition = TRUE;
pthread_cond_signal(&cond);

То ясно что если я переменную condition меняю не под мутексом - отгребу. Но вот почему  pthread_cond_signal должен быть внутри - хз

А еще лучше!

Ну и чего ото делать вид что это якобы очевидно? Не надо бояться сказать "не знаю", это часто проще и лучше

[Old]

Ну и чего ото делать вид что это якобы очевидно?

Для меня да. Вызов pthread_cond_signal(&cond); это доступ к разделяемому ресурсу без защиты мьютексом. Может быть все что угодно в зависимости от реализации.

Не надо бояться сказать "не знаю", это часто проще и лучше

Проще учиться думать и разбираться самому, а не спрашивать по форумам.

[Igors]

Проще учиться думать и разбираться самому, а не спрашивать по форумам.

А я и не просил Вас ни о какой помощи Просто интересно "почему". Хорошо, вот еще попытка доказательства

This is valid:

void *threadproc(void *data) {
    printf("Sending go signal\n");
    go = 1;
    pthread_cond_signal(&cond);
}

However, consider what's happening in main

while(!go) {
    /* Suppose a long delay happens here, during which the signal is sent */
    pthread_cond_wait(&cond, &lock);
}

If the delay described by that comment happens, pthread_cond_wait will be left waiting—possibly forever. This is why you want to signal with the mutex locked

Обратите внимание что вызов pthread_cond_signal не требует защиты (то же и в др источниках). Да, побудка будет упущена, в этом автор прав. Но как мы знаем, само по себе это не криминал. Если до того мы взвели go (под защитой) - то должно работать, задача не пропускается

Код

C++ (Qt)
pthread_mutex_lock(&lock); 
go = 1;
pthread_mutex_unlock(&lock);
pthread_cond_signal(&cond);
 

Или я ошибаюсь?

[Old]

Или я ошибаюсь?

Если несколько ниток будут писать и читать int без защиты мьютексом, будет работать?
Вроде будет, а потом... а на другой платформе... а на другой архитектуре...

Поэтому, мне совершенно не понятно, что доказывает (или не доказывает) этот пример.
Еще раз, я думаю, что разработчики pthread настаивают на вызове signal под защитой мьютекса, потому что в реализации самих функций работы с условной переменной (pthread_cond_xxx) могут быть "тонкие места", а не в пользовательском коде.

[Igors]

Если несколько ниток будут писать и читать int без защиты мьютексом, будет работать?

Как ни странно, в схеме WaitCondition - будет За счет второй переменной которая строго под мутексом.

Вроде будет, а потом... а на другой платформе... а на другой архитектуре...

Да конечно практичнее впихнуть под мутекс чем разбираться - я ж с этим не спорю. Но какой-то Вы совсем не любознательный, хотя еще молодой 

[Old]

Но какой-то Вы совсем не любознательный, хотя еще молодой  

А в чем здесь любознательность? Сейчас условные переменные реализовали так, завтра их реализуют по другому, под какой нибудь вендой по третьему? Мне нужно все изучить? Любознательный вы наш?

хотя еще молодой 

Нуу 40 лет это не возраст для мужчины.