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

Сообщение отредактировал AD - 18.11.2011, 8:30

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

Да я там посмотрел. Понятно, что ими вполне можно пользоваться, но с универа помню, что чем-то они плохи и им есть какая-то альтернатива. Два минуса я знаю - возникновения dead lock и возникновения состояния "гонки" (понятное дело, что такие ситуации возникают при некорректном использовании мьютексов).

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

Причем здесь системное или нет? Извини, но я ведь задал конкретный вопрос, относящийся есть ли альтернативы или нет? Судя по твоим постам, альтернативы нет?

вообще, если программист так уж боится собственного кода, то есть более "безопасные" реализации.
в бусте, например, есть разные вариации на базе мьютексов: boost::mutex::scoped_lock, timed_lock и т.д. это просто концепции использования мьютексов:

Lockable Concept
TimedLockable Concept
SharedLockable Concept
UpgradeLockable Concept
http://www.boost.org/doc/libs/1_47_0/doc/h...ronization.html

кроме того, есть семафоры, барьеры, условные переменные. да много всяких реализаций. но большинство из них базируется на системных средствах: мьютексах и семафорах.

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


не во всех системах. скажем так.
это НЕ софтовая фича. это системная функция. вопрос лишь в том, поддерживает система ту или иную схему синхронизации или нет.
как я уже написала, большинство систем поддерживают мьютексы. остальное чаще всего нагорожено поверх них, с помощью софта.
в ядре линюкса есть семафоры и спинлоки (мьютекс - частный случай семафора):
http://www.ibm.com/developerworks/linux/li...tion/index.html
в венде есть мьютексы, спинлоки и куча фич у ядра, для драйверов:
http://msdn.microsoft.com/en-us/windows/hardware/gg487425
в других системах что-то похожее.
POSIX декларирует мьютексы и семафоры:
http://www.yolinux.com/TUTORIALS/LinuxTuto...sixThreads.html
но не факт, что всякие дополнительные фичи реализованы в каждой системе.

ты всегда можешь взять документацию на API целевой системы и посмотреть, что там предлагается для работы с синхронизацией. но для кроссплатформы это либо какая-то библиотечная обёртка (тот же буст, или Qt, или порты pthread), либо куча #ifdef'ов и очень некрасивый и сложно поддерживаемый код.

Сообщение отредактировал Iron Bug - 18.11.2011, 9:40

Для некоторых решений можно использовать: Атомарные операции
Конечно, как полную замену системным механизмам я бы их не рассматривал.

Сообщение отредактировал BRE - 18.11.2011, 10:27

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

Сообщение отредактировал Iron Bug - 18.11.2011, 10:36

Я бы их назвал аппаратным средством, а не системным.
Под системным я подразумевал средства ОС.


Сообщение отредактировал BRE - 18.11.2011, 10:39

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

скажем так, даже драйвер не может напрямую управлять железом. для этого у него есть интерфейсы ядра и они далеко не всегда означают непосредственные манипуляции с железом. а сейчас и вовсе идёт тенденция к созданию некоего общего фреймворка, чтобы драйвер вообще не имел дела непосредственно с железом, только с обобщёнными функциями этого фреймворка. сюда относится и интелловская идея "продвинутого" биоса, который запускает ось наподобие виртуальной машиены, и вендозный KMDF.

Сообщение отредактировал Iron Bug - 18.11.2011, 10:50