Неожиданно обнаружил очень давно увиденный и, казалось, навсегда потерянный очень приятный текст: "Multithreaded Programming Guide" от Sun

Вот тут http://www4.ncsu.edu/~rhee/clas/csc495j/MultithreadedProgrammingGuide_Solaris24.pdf от 1994-го еще года,

а тут http://docs.oracle.com/cd/E19253-01/816-5137/816-5137.pdf за 2008-й год, раза в полтора потолще.

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

Помимо скорее уже ошибочных мест, мне вот этот пассаж не понятен:

This function [pthread_cond_wait] blocks until the condition is signaled. The function atomically releases the associated mutex lock before blocking, and atomically acquires the mutex again before returning.

Вот это второе "atomically" несколько непонятно, при том, что в Sun-овской документации http://www.manpages.info/sunos/pthread_cond_wait.3.html его вообще нет. Что они понимают под этой атомарностью? Т.е. может они мютекс перебрасывают от одного треда к другому от того треда, который просигналил - к тем, которые сигнал приняли, но ведь просигналить можно и за пределами мютекса, так что... Вообще, гадать можно, но что ж они на самом деле в виду имели?

Вот еще забавный пассажик, надолго извративший понимание темы (оно до сих пор извращено):

Since pthread_cond_broadcast() causes all threads blocked on the condition to contend again for the mutex lock, use pthread_cond_broadcast() with care.

На самом деле, это pthread_cond_signal надо использовать с осторожностью, а если вам приходится с острожностью использовать pthread_cond_broadcast - это скорее всего означает, что у вас ошибочный код. Вообще, pthread_cond_broadcast должна бы по идее объясняться первой и быть "дефолтной" функцией сигнализации, а pthread_cond_signal вводиться как некая опасная оптимизация, частный специализированный случай броадкаста. Но такой взгляд на вещи пока распространения не получил.