Хмм, думаю вот на такой проблемой. Допустим, есть защищенный ресурс. Хочу опеспечить доступ к нему нескольких потоков в порядке FIFO (читаем текст внимательно, не путать c "producer-consumer + fifo queue", очередь в данном случае именно из клиентов, т.е. потоков, количество которых варьируется). Т.к. ни mutex'ы, ни cond'ы не гарантируют определенности в таком вопросе, как "какой именно поток сейчас будет разблокирован" (хотя часто там FIFO, но это уже implementation details, и на это полагаться нельзя), то существует определенная проблема. Надумал 3 варианта: 1. Каждый поток блокируется на своей условной переменной. Проблем нет, сам формирую очередь, при освобождении ресурса каждый поток пробуждает следующий поток из головы очереди pthread_cond_signal'ом на его условную переменную. Плюсы: должно быстро работать; Минусы: дополнительный расход памяти под очередь и усл. переменные. 2. Все потоки блокируются на одной условной переменной. При этом в предикате как раз проверяется условие "находится ли текущий поток в голове очереди?". При освобождении ресурса каждый поток пробуждает всех waiter'ов через pthread_cond_broadcast. Минусы: ужасно индусский медленный способ (каждый поток пробуждается все-таки, потом опять блокируется, много лишних переключений контекста - в Linux'овой NPTL, например, системный вызов futex дергаеццо). 3. SCHED_FIFO. Короче, решение задачи "в лоб". Слишком неудачный метод. Т.к. realtime бывает совсем не нужно, да и привилегии нужны для получения. Короче говоря, пока я за первый вариант. Но, кто знает, вдруг есть еще способы.)
Из перечисленных вариантов, первый звучит хорошо, но... Сама задача звучит несколько странно. Что при таком алгоритме работает лучше/быстрее? При модели равноправных worker-threads обычно наоборот стараются использовать потоки, которые недавно отработали.
