Я не уверен, что понимаю обоснование того, как вы делаете
вещи. В обычной идиоме «потребитель-провайдер» провайдер выдвигает
как можно больше элементов в канал, ожидая, только если есть
недостаточно места в канале; это не ждет пустого. Итак
обычная идиома будет:
провайдер (чтобы нажать одну вещь):
pthread_mutex_lock( &mutex );
while ( ! spaceAvailable() ) {
pthread_cond_wait( &spaceAvailableCondition, &mutex );
}
pushTheItem();
pthread_cond_signal( &itemAvailableCondition );
pthread_mutex_unlock( &mutex );
и на стороне потребителя, чтобы получить предмет:
pthread_mutex_lock( &mutex );
while ( ! itemAvailable() ) {
pthread_cond_wait( &itemAvailableCondition, &mutex );
}
getTheItem();
pthread_cond_signal( &spaceAvailableCondition );
pthread_mutex_unlock( &mutex );
Обратите внимание, что для каждого условия одна сторона сигнализирует, а другая ждет. (Я
не вижу ожидания у вашего потребителя.) И если есть более одного
процесс с любой стороны, я бы рекомендовал использовать pthread_cond_broadcast
,
а не pthread_cond_signal
.
В вашем коде есть ряд других проблем. Некоторые из них выглядят более
как опечатки: вы должны скопировать / вставить реальный код, чтобы избежать этого. Вы
действительно означает читать и выдавать mGeneratedValues
, когда вы нажимаете в
mGeneratedNumber
и проверить, пусто ли это? (Если вы на самом деле
есть две разные очереди, то вы выскочите из очереди, где нет
один нажал.) И у вас нет никаких петель, ожидающих
условия; вы продолжаете перебирать количество элементов, которые вы
ожидать (увеличивая счетчик каждый раз, так что вы, вероятно,
прорасти задолго до того, как ты это сделаешь) - я не вижу бесконечной петли,
но я легко могу видеть бесконечное ожидание в pthread_cond_wait
в
режиссер. Я не вижу сброса ядра с рук, но что происходит, когда один
из процессов заканчивается (вероятно, потребитель, потому что он никогда
ждет чего угодно); если это в конечном итоге уничтожает мьютекс или условие
переменных, вы можете получить дамп ядра, когда другой процесс пытается
используйте их.