История изменений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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