Anatoly MoskovskyАнатолий ШироковЯ отвечал на конкретный пост относительно предложения приоткрыть завесу "потрохов" объектов ядра для клиентского кода и невозможность это сделать в контексте обеспечения безопасности ядра, кроме как через легальный API. Ясно, что в случае мьютексов надо было бы перенести на пользовательский уровень и много чего другого для обеспечения имитации функционала API .
Кроме безопасности нет никаких преград для реализации мьютекса в юзерспейсе. С таким же эффектом можно сказать, для свободного полета человека нет никаких преград кроме законов физики. Слишком общо.

Если речь все еще идет о конкретном виндовом объекте ядра Mutex Object, то как можно реализовать весь его функционал в юзерспейсе? А именно обеспечение равных шансов захвата всеми конкурирующими потоками (при многократном захвате), таймауты, сигнализация, да и вообще все что отличает его от спин-блокировки? Кто будет сообщать другим потокам\процессам о том что мьютекс освободился? Кто будет принимать решение какой из ждущих потоков будить? Как вообще планировать задачи (потоки, процессы) из юзерспейс кода?

Поток\процесс пытается захватить мьютекс. Вызывается какой-нибудб interlocked_exchange и поток понимает что - облом мьютекс уже захвачен. Вопрос что он должен делать? Видится три варианта

1. Дико exch-ить пока не получится захватить.
2. Делать №1 с какой-либо периодичностью с засыпаниями (что неизбежно приводит к вызову контекста ядра, так как идет вызов планировщика).

Тем не менее 1, 2 - это варианты спин блокировки, и речь не о них, речь ведь о конкретном объекте ядра винды - Mutex Object.

3. Нужно как-то попросить ядро чтобы она сообщила когда потоку можно будет попробовать захватить мьютекс еще раз и тут же заснуть. Заметили словосочетание попросить ядро? А там таких молящих о помощи еще с десяток. Их надо где-то держать. Их надо планировать. Равномерно давать подержать мьютекс. Пинать по таймауту. А если еще учесть что мьютексом владеет захвативший поток, следить за ним, чтобы он не помер вместе с мьютексом, а если он все таки умудрится это сделать, пометить мьютекс как свободный.

Будет интересно послушать ктО это все будет делать как не ядро и причем тут безопасность.. Говорю без сарказма, потому-что есть много док которые надо прочитать, где предпринимаются попытки найти ктО, поэтому будет действительно интересно и полезно послушать развернутые ответы на эти вопросы.

Anatoly MoskovskyВот в общих чертах как мог бы выглядеть юзерспейс мьютекс под виндой.
(В терминах существующего АПИ)
Создается именованный объект Event и в разделяемой памяти создается спинлок (атомарный флаг).
При блокировке юзер сначала пытается блокировать спинлок, если удается - операция завершена.
Если не удается, то юзер вызывает WaitForSO для ивента.
При разблокировке, юзер разблокирует спинлок и сигнализирует в ивент.
Все.
Когда нет конкурентов юзер вообще не переключается в ядро.
Единственная проблема - безопасность. Другие юзеры могуд повредить спинлок. Вы только что изобрели CRITICAL_SECTION. О разнице между ним и Mutex Object вобщем-то и толковали.

Anatoly Moskovskysherzod_Вы только что изобрели CRITICAL_SECTION. О разнице между ним и Mutex Object вобщем-то и толковали.
У секций нет механизма аналогичного event. Это просто флаг и список усыпленных потоков. Из других процессов вы не можете к ней обращаться.
А то что я привел - это именно межпроцессный мьютекс. Ах вот вы о чем. О межпроцессной критической секции. Все таки не о виндовом объекте мьютекс с описанным в п3 поведением, потому что не совсем понятно какие будут распределния захвата и поведение, как будет учитываться приоритет задач и тд. ЕМНИП подобный функцонал приводится у Рихтера в качестве примера, класс Optex.