Почему mutex::unlock нужно вызывать из того же потока, что и mutex::lock?

Кто нибудь знает зачем std::mutex нужно разблокировать из того же потока, который заблокировал его.

Это требование элементарной логики и нижележащих реализаций (pthread etc).

Без этого требования можно было бы блокировать mutex из одного потока два раза, и разблокировать из другого.

А смысл?

Потому что это нормально. И для того, что бы реализовать события - есть другие структуры, предназначенные для этого, и называющиеся по другому.

Кто нибудь знает зачем std::mutex нужно разблокировать из того же потока, который заблокировал его.

А что толку от mutex, если его может разблокировать кто хочет? Т.е. поток захватывает ресурс, а у него его отбирают без какого-либо уведомления, это же сводит на нет весь смысл защиты ресурсов.

Без этого требования можно было бы блокировать mutex из одного потока два раза

Это уже рекурсивный mutex, и при этом поток не блокируется. mutex по определению ничего не считает, считает семафор. А mutex это специальный частный случай семафора. Как уже сказали, не надо пытаться реализовать всю синхронизацию на одном примитиве; их больше одного не просто так.

Потому что объект синхронизации, который можно захватывать и отпускать из разных потоков, называется семафор, а не мьютекс.

Потому что гладиолус

Ок, спасибо за решение, которое избавляет от использования futex syscall напрямую. Однако, все равно хочется понять, зачем разработчики posix наложили такое ограничение на mutex. Наверняка у них была на это причина.

избавляет от использования futex syscall напрямую

Ты хоть читал man 7 futex?

PTHREAD_PROCESS_SHARED

PTHREAD_PROCESS_SHARED

Спасибо за информацию.

Не занимайся извращениями с двойными блокировками, а открой для себя семафоры и условные переменные (или изучи еще раз, если думаешь, что ты их понимаешь).

блокировать mutex из одного потока два раза, и разблокировать из другого

pthread_barrier_wait

futex в Linux, на основе которого реализованы mutex и условные переменные не имеет такого ограничения

Люди уже забыли историю адобе и мемкопи?

http://en.wikipedia.org/wiki/Semaphore_(programming)#Semaphores_vs._mutexes

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

Осиль концепцию владения

Еще после прочтения предыдущего комментария, я сделал вывод, что в mutex реализована концепция владения (кто вызвал lock, тот и владеет mutex'ом, а заодно и ресурсом к которому он дает эксклюзивный доступ, а соответственно только владелец может вызвать unlock).

У меня изначально было другое представление. Я считал mutex простым флагом, который указывает занял ли ресурс, к которому требуется эксклюзивный доступ или нет (плюс взаимодействие с ядром, чтобы процесс, которому нужно подождать доступа находился в очереди спящего ожидания). При такой семантике mutex нужен лишь для того, чтобы подождать пока флажок не будет освобожден и тут нет понятия владения (флажок занят - ждем, свободен - занимаем и начинаем обработку). Тогда возможна такая ситуация, что один поток захватил флаг, получил доступ к ресурсу, начал его обработку, передал его другому вместе с флагом, а тот закончил обработку и в результате освободил флаг. Как оказалось, такая семантика не у mutex, а у бинарного семафора.

Кроме того, недопонимания добавляет тот факт, что mutex'у не нужна семантика владения. Если разрешить делать unlock произвольному потоку, то mutex сможет точно так же реализовывать свое обычное поведение, а кроме этого делать другие вещи, которые сейчас запрещены. Т.е. mutex без семантики владения станет гибче в использовании. Более того, именно так mutex и реализован в Linux. Вот именно это мне и было не понятно, зачем создатели posix наложили требование на необходимость делать unlock в том же потоке, если без него все работает точно так же и еще открываются дополнительные возможности (или коротко, зачем mutex'у концепция владения, чего бы не сделать его как бинарный семафор).

Всем, кто отписался по делу - спасибо.

Если речь идет не о доступе к ресурсу, а об «обработке» - то это совсем другое и тебе становится нужен не «захват» ресурса, а банальное уведомление о завершении обработки. И тут на выбор или семафор или condition variable.

Еще раз пойми - 1. мьютекс без семантики владения - это тот же семафор в контесте использования. Отдельной сущности «мьютекс» тогда вообще не нужно. 2. Ты словно как пропустил важный момент про оптимизацию планирования процессов - http://en.wikipedia.org/wiki/Priority_inversion. Именно она делает использование мьютексов для эксклюзивной блокировки ресурсов выгодным относительно того же семафора. Без семантики владения это невозможно.