как устроен Mutex, Event

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

Но сразу понял что это полная глупость

Это не глупость, это spin-lock. В некоторых ситуациях может быть оправдано.

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

За них же ядро отвечает. Планировщик выбрасывает ожидающий мьютекс процесс из очереди на выполнение, а когда мьютекс освобождается - помещает назад.

посмотри в исходниках ядра реализацию :P

ну правда, что я как маленький, там же уже все ответы есть :)

Спасибо за объяснения. Концепт понятен.

А с эвентами похожая ситуация ?

А с эвентами похожая ситуация ?

Да.

*Таненбаум*

В Рихтере почитай. Ну или в том же Таненбауме.

При освбождении мьютекса другим процессом первая ожидающая его задача перемещается в очередь на выполнение и будет вскоре запущена планировщиком задач

Это в какой операционной системе так?

В винде сохранение порядка блокировки/разблокировки у критических секций выпилили где-то в первой половине нулевых, в линаксе вообще не помню, что-бы оно когда-нибудь было

spin-lock (таки да, в цикле - busy wait называется).
А комманды cmpxchg или test and setlock гарантируют атомарность.

подробнее смотреть в исходниках ведра и книжках типа Танненбаума :)

Первая - это для простоты сказано.

Сдается мне, что мьютексы работают так: ядро выделяет в разделяемой памяти некоторую область, куда помещается метка - идентификатор мьютекса; если поток хочет заблокировать мьютекс, а метка уже есть, то блокировка не удается. Ядро пытается гарантировать атомарность этой операции, но сдается мне, что race conditions на многоядерных (скажем, 1024 ядра) системах вполне могут привести с ненулевой вероятностью к коллизии при блокировке мьютекса, если вдруг случится так, что выполняющиеся на соседних ядрах потоки одновременно попытаются его заблокировать.

А что, в школе ещё каникулы?

Чего ты с него хочешь, он К.Т.Н.

В Рихтере почитай.

это же не винфак

это же не винфак

Тем не менее, Event-ы, упомянутые в ОП, есть виндовые примитивы синхронизации

При освбождении мьютекса другим процессом первая ожидающая его задача перемещается в очередь на выполнение

Именно - первая ожидающая, а не наиболее приоритетная. Вход RT патча в состав ванильного ядра в будущем решит эту проблему.

race conditions на многоядерных (скажем, 1024 ядра) системах вполне могут привести с ненулевой вероятностью к коллизии при блокировке мьютекса

Обращение к мьютексу в ядре можно защитить спинлоком, а его атомарность гарантируется в конченом счете аппаратно, даже если 1024 ядра.

man 7 futex