Я не вижу действительного варианта использования для этого, и мне интересно, почему это когда-либо будет иметь значение. Вы не должны быть , вызывая pthread_cond_wait
с недопустимой условной переменной.
Если вы беспокоитесь об этом, просто измените код с:
pthread_cond_wait (pcv, pmutex);
что-то вроде:
if (pcv != NULL) pthread_cond_wait (pcv, pmutex);
и он не будет вызываться с NULL.
Я подозреваю, что это было введено как "возможно" просто потому, что была реализация pthreads (возможно, даже самих исходных потоков DEC), которая не возвращала код ошибки для этого обстоятельства.
Но, поскольку альтернатива почти наверняка состоит в том, что все это рухнуло в кучу, я бы не стал на это полагаться: -)
Если вы беспокоитесь об атомарности этого кода, вам не нужно об этом. Просто используйте тот же мьютекс, который защищает переменную условия, чтобы защитить указатель CV, содержащийся в вашем списке:
claim mutex A
somenode->cv = NULL
release mutex A
и, в вашем цикле код:
claim mutex A
if loopnode->cv != null:
wait on condvar loopnode->cv using mutex A
// mutex A is locked again
: : :
Тот факт, что мьютекс заблокирован как во время if
, так и при вызове pthread_condvar_wait
, означает, что не может быть никакого состояния гонки. Ничто не может изменить переменные условия узла, пока зацикленный поток не освободит мьютекс в вызове pthread_condvar_wait
. И к тому времени вызов использует свою собственную локальную копию указателя, поэтому изменение его в списке не будет иметь никакого эффекта.
И, если код, изменяющий узлы, захватывает мьютекс, if
и pthread_condvar_wait
не могут выполняться, пока этот мьютекс не будет освобожден.