А нафига существуют мьютексы, когда есть семафоры?

это шутка?

это шутка?

Конечно, как же может быть иначе!

Семафоры штука хорошая, но больно тяжелая.

зачем сделали косинус, если его все равно можно получить из синуса?

зачем сделали косинус, если его все равно можно получить из синуса?

С инженерной точки зрения - пёс его знает, аналогично сабжу.

И зачем существует интеграл Римана, если есть интеграл Лебега

Семафоры штука хорошая, но больно тяжелая.

А нельзя было лёгкий сделать? Бросить на это лучшие умы и победить?

давай определение мьютекса

давай определение мьютекса

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

Примитив синхронизации, позволяющий реализовать «критическую секцию» — гарантировать исполнение некоего куска кода только одним тредом.

Задача мьютекса — защита объекта от доступа к нему других потоков, отличных от того, который завладел мьютексом. В каждый конкретный момент только один поток может владеть объектом, защищённым мьютексом. Если другому потоку будет нужен доступ к переменной, защищённой мьютексом, то этот поток блокируется до тех пор, пока мьютекс не будет освобождён.

Mutex - это частный случай семафора и всего то

Мьютекс это одноместный семафор. Наркоманы вы проклятые.

Mutex - это частный случай семафора и всего то

А нафига было плодить частные случаи в виде отдельных концепций? Никто ж не делает в файловой системе разные типа .txt файлов — один типа для блокнота, второй для логов...

Потому что в 90% случаев нужен одноместный лок. Просто одноместный лок. И реализовуют его как семафор. А могут на критических секциях сделать.

А семафор на критических секциях не сделаешь нормально

А семафор на критических секциях не сделаешь нормально

А чё такое вообще «семафор на критических секциях»? Семафор - туда можно постить (инкрементить) и декрементить инты, как это вообще на критических секциях можно даже ПОДУМАТЬ сделать? )

типа xml/html/любые другие форматы файлов, которые можно открыть текстовым редактором тоже txt, хотя обратное не верно.

большинство мьютексов на критических секциях, т.к. IPC нафиг не нужен

Самое главное различие в том, что мьютекс может быть освобожден только захватившим его потоком (захватил, что-то сделал, освободил), а семафор может захватываться и освобождаться разными потоками (Поток А: я готов обработать следующий запрос, подожду-ка я семафор. Поток Б: пришла следующая порция данных, поставлю в очередь, просигналю семафором)

Бывают рекурсивные мютексы, рекурсивных семафоров не встречал.

Семафор можно сделать и не IPC, внутрипроцессный семафор.

Ну вот они и сделали. И назвали его мьютекс.

Самое главное различие в том, что мьютекс может быть освобожден только захватившим его потоком

Это утверждение из теории или из практики? Так-то в Linux тредах лочить можно в одном треде, а разлачивать в другом. Хотя такое пожалуй редко используется.

Упал штоле?

Attempting to unlock the mutex if it was not locked by the calling thread results in undefined behavior.

Упал штоле?

Чорт!
Точно UB. Хотя тестовый пример работал. Но на то оно и UB.

У него другая семантика.

Это позволяет делать всякий ThreadSafetyAnalysis с аннотациями вида GUARDED_BY, который проверяет, что общие данные меняются только под мьютексом, ищет потенциальные дедлоки. Описывать это в терминах семафоров было бы странно.

Ещё модели памяти с acquire/release-операциями позволяют при работе с мьютексом сбрасывать только нужные кеши (семафор, который при уменьшении на один обладал бы acquire-семантикой, а при увеличении на 1 — release-семантикой, был бы странным).

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

Ещё есть более сложные примитивы синхронизации, например, conditional variables. Они уже зависят от мьютексов.

Самый полный ответ в треде. Спасибо.

В крутых планировщиках знают, что нормальные программы под мьютексом долго не сидят, и чуть дольше не вытесняют нить, если она недавно захватила мьютекс.

Захват mutex - это запись в атомарную переменную. Как планировщик в ядре узнает про запись в переменную в пользовательском процессе?

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

Или, может, в Linux реализовали то, о чем я мечтаю - некую атомарную переменную, отображенную в ядро, запись в которую означает, что userspace просит не переключать его некоторое время и планировщик в ядре учитывает этот флаг (например, встретив его в первый раз, сохраняет timestamp, а встретив второй раз сравнивает сохраненный timestamp и решает подождать с переключением еще или, таки, переключить задачу и таким образом исключает злоупотребления).

К сожалению, реализовано не в линуксе. Мьютекс правда там немного хитрее, чем запись в атомарную переменную, но всё ещё не требует сисколла при маленьком contention.

Реализовано примерно как описано в последнем абзаце — тред при захвате мьютекса пишет rdtsc куда-то в район [gs:8192], то место, которое решает, запускать ли планировщик, это учитывает.

В системе же два варианта мьютекса можно создать - для тредов внутри процесса и для синхронизации разных процессов. Наверное это всех путает :)

Нафиг нужны семафоры, когда есть мьютексы? Я вот честно — мьютексами часто пользуюсь, а семафорами не пользовался никогда!

А уж механика Лагранжа - это единственное, что нужно знать, взвешивая картошку на рычажных весах.

Единственно верный ответ: https://www.youtube.com/watch?v=Vn29DvMITu4