Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Мьютексы
Форум на CrossPlatform.RU > Разработка > С\С++
AD
Хотел бы задать вопрос для того, чтобы вспомнить позабытые со времен университета вещи. Чем плохи мьютексы? Какие есть альтернативы мьютексам? Хотелось бы вкратце вспомнить! За ссылки на какие-то краткие описания буду благодарен, а вот на толстые учебники, спасибо, но не надо. Просто хочется освежить знания.
Iron Bug
а почему сразу плохи? мьютекс - просто одно из средств синхронизации, частный случай одномерного семафора, которое поддерживается практически всеми осями. наверное, даже вообще всеми.
на основе мьютексов нагорожена куча разных методов синхронизации в разных библиотеках.
кратко о мьютексах - википедия.
AD
Цитата(Iron Bug @ 18.11.2011, 9:38) *
а почему сразу плохи? мьютекс - просто одно из средств синхронизации, частный случай одномерного семафора, которое поддерживается практически всеми осями. наверное, даже вообще всеми.
на основе мьютексов нагорожена куча разных методов синхронизации в разных библиотеках.
кратко о мьютексах - википедия.

Да я там посмотрел. Понятно, что ими вполне можно пользоваться, но с универа помню, что чем-то они плохи и им есть какая-то альтернатива. Два минуса я знаю - возникновения dead lock и возникновения состояния "гонки" (понятное дело, что такие ситуации возникают при некорректном использовании мьютексов).
Iron Bug
глупости. конечно, программисту никто не запрещает написать глючный код, но лучше этого всё-таки не делать :)
мьютексы - системное средство синхронизации. ни больше и ни меньше. просто средство, с системной поддержкой.
я себе слабо представляю программу, в которой они НЕ используются, явно или неявно. разве что какие-то простейшие однопоточные приложения, которые пишут студенты для зачётов.
AD
Цитата(Iron Bug @ 18.11.2011, 10:12) *
глупости. конечно, программисту никто не запрещает написать глючный код, но лучше этого всё-таки не делать :)
мьютексы - системное средство синхронизации. ни больше и ни меньше. просто средство, с системной поддержкой.
я себе слабо представляю программу, в которой они НЕ используются, явно или неявно. разве что какие-то простейшие однопоточные приложения, которые пишут студенты для зачётов.

Причем здесь системное или нет? Извини, но я ведь задал конкретный вопрос, относящийся есть ли альтернативы или нет? Судя по твоим постам, альтернативы нет?
Iron Bug
вообще, если программист так уж боится собственного кода, то есть более "безопасные" реализации.
в бусте, например, есть разные вариации на базе мьютексов: 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

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

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

Цитата(AD @ 18.11.2011, 12:21) *
Причем здесь системное или нет? Извини, но я ведь задал конкретный вопрос, относящийся есть ли альтернативы или нет? Судя по твоим постам, альтернативы нет?

не во всех системах. скажем так.
это НЕ софтовая фича. это системная функция. вопрос лишь в том, поддерживает система ту или иную схему синхронизации или нет.
как я уже написала, большинство систем поддерживают мьютексы. остальное чаще всего нагорожено поверх них, с помощью софта.
в ядре линюкса есть семафоры и спинлоки (мьютекс - частный случай семафора):
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'ов и очень некрасивый и сложно поддерживаемый код.
BRE
Цитата(AD @ 18.11.2011, 9:30) *
Какие есть альтернативы мьютексам?

Для некоторых решений можно использовать: Атомарные операции
Конечно, как полную замену системным механизмам я бы их не рассматривал. :)
Iron Bug
Цитата(BRE @ 18.11.2011, 13:25) *
как полную замену системным механизмам я бы их не рассматривал

атомарные операии - тоже системный механизм :) чисто ассемблерная фича, даже ещё более приближенная к железу, нежели мьютексы. там вообще обращения на уровне команд железу. так реализовано выставление адресов на шине, например, и многие другие системные операции с адресами и общей памятью.
более крупные "атомарные операции" реализованы с помощью софта, на базе мьютексов.
BRE
Цитата(Iron Bug @ 18.11.2011, 11:32) *
Цитата(BRE @ 18.11.2011, 13:25) *
как полную замену системным механизмам я бы их не рассматривал

атомарные операии - тоже системный механизм :)

Я бы их назвал аппаратным средством, а не системным.
Под системным я подразумевал средства ОС.
Iron Bug
Цитата(BRE @ 18.11.2011, 13:38) *
Я бы их назвал аппаратным средством, а не системным.

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

скажем так, даже драйвер не может напрямую управлять железом. для этого у него есть интерфейсы ядра и они далеко не всегда означают непосредственные манипуляции с железом. а сейчас и вовсе идёт тенденция к созданию некоего общего фреймворка, чтобы драйвер вообще не имел дела непосредственно с железом, только с обобщёнными функциями этого фреймворка. сюда относится и интелловская идея "продвинутого" биоса, который запускает ось наподобие виртуальной машиены, и вендозный KMDF.
BRE
Цитата(Iron Bug @ 18.11.2011, 11:45) *
просто юзер не может напрямую юзать аппаратные средства. доступ к некоторым реализован через системные интерфейсы и юзерские API. поэтому для программиста верхнего (по сравнению с системным) уровня аппаратных средств, как таковых, не существует. есть только системные.

Если выбросить ОС, то системных средств у программиста не останется, а аппаратные будут все еще доступны. :)
С помощью ассемблера программист верхнего уровня может получить доступ к определенным аппаратным средствам. Сделать все те же атомарные операции.
Iron Bug
Цитата(BRE @ 18.11.2011, 13:56) *
Цитата(Iron Bug @ 18.11.2011, 11:45) *
просто юзер не может напрямую юзать аппаратные средства. доступ к некоторым реализован через системные интерфейсы и юзерские API. поэтому для программиста верхнего (по сравнению с системным) уровня аппаратных средств, как таковых, не существует. есть только системные.

Если выбросить ОС, то системных средств у программиста не останется, а аппаратные будут все еще доступны. :)
С помощью ассемблера программист верхнего уровня может получить доступ к определенным аппаратным средствам. Сделать все те же атомарные операции.

последняя такая система на моей памяти была Windows 98: она позволяла получить доступ к портам. более современные системы НЕ ПОЗВОЛЯЮТ юзеру работать напрямую с железом никоим образом. потому что это просто нарушит работу системы и безопасность.
железо постоянно меняется. причём очень быстро. даже системные программисты не имеют дел непосредственно с железом. на то есть специальные системные вызовы. иначе был бы полный капец разработке: учитывать особенности каждой конфигурации железа и все изменения протоколов по всем устройствам просто нереально. система для того и существует, чтобы избавлять юзера от всего этого геморроя.
конечно, можно снести систему. и работать с железом. писать код прямо в память при старте (а комп без софта умеет только грузить бутрекорд на старте и больше нихрена, ну, есть ещё базовые функции биос, но они актуальны только для получения общей информации о присутствующем железе). но будет очень грустно. особенно потому, что даже система НЕ РАБОТАЕТ напрямую с регистрами процессора. в процессор зашивается микрокод, который сам выполняет множество операций, упрощая и значительно ускоряя работу системы. вообще говоря, при разном микрокоде это будут совершенно разные устройства.
просто я каждый день с такими вещами дело имею. тут всё не так просто, как кажется юзеру верхнего уровня.
BRE
Цитата(Iron Bug @ 18.11.2011, 12:23) *
последняя такая система на моей памяти была Windows 98: она позволяла получить доступ к портам. более современные системы НЕ ПОЗВОЛЯЮТ юзеру работать напрямую с железом никоим образом. потому что это просто нарушит работу системы и безопасность.

Ну и что? Зачем мне порты для реализации атомарных операций?
Другое дело нужно ли это? Я завязал с ассемблером, когда Пеньтиумы покорили мир, мне стало не интересно соревноваться с компиляторами в оптимизации кода. А до этого я занимался разработкой на ассемблере системного софта, который работал в защищенном режиме. Это времена MSDOS и Win3.1.

Цитата(Iron Bug @ 18.11.2011, 12:23) *
железо постоянно меняется. причём очень быстро. даже системные программисты не имеют дел непосредственно с железом. на то есть специальные системные вызовы. иначе был бы полный капец разработке: учитывать особенности каждой конфигурации железа и все изменения протоколов по всем устройствам просто нереально. система для того и существует, чтобы избавлять юзера от всего этого геморроя.

А это вторая причина по которой использовать ассемблер сейчас я считаю делом малоперспективным. :)

Цитата(Iron Bug @ 18.11.2011, 12:23) *
конечно, можно снести систему. и работать с железом.

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

Цитата(Iron Bug @ 18.11.2011, 12:23) *
а комп без софта умеет только грузить бутрекорд на старте и больше нихрена

Не не, это делает BIOS. Сама железка может начать выполнять инструкции из памяти с определенного адрес.

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

Цитата(BRE @ 18.11.2011, 14:55) *
это делает BIOS.

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

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

это уже глубокий хардварный оффтоп :)
BRE
Цитата(Iron Bug @ 18.11.2011, 13:16) *
атомарность - не обращение к железу.

Это ты начала :)
Цитата
атомарные операии - тоже системный механизм :) чисто ассемблерная фича, даже ещё более приближенная к железу, нежели мьютексы.

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

Цитата(Iron Bug @ 18.11.2011, 13:16) *
ну да. просто я имею в виду без оси. биос поставляет производитель железа, это не относится к оси. без него вообще ничего не будет работать: только выдирать флэшку и перепрошивать программатором :)

BIOS это обычное программное обеспечение, которое пишет программист, и если вместо него написать свое и прошить его в ROM, то оно спокойно будет работать. :)

Цитата(Iron Bug @ 18.11.2011, 13:16) *
смысл-то был в том, что юзер в принципе не должен управлять железом. а если он очень хочет, то нужно писать сначала драйвер кернел мода(в этой области я уже не умею говорить по-русски :) ), потом, возможно, драйвер юзерского уровня - для повышения эффективности использования и программирования политик и интерфейсов. и уже потом юзать вызовы своего драйвера верхнего уровня.

Это ты говоришь про то как это устроено в массовом секторе, но есть железки у которых нет ОС и нет такого понятия как модуль ядра в принципе.
Для таких железок тоже пишут программное обеспечение. :)
Iron Bug
Цитата(BRE @ 18.11.2011, 15:38) *
Это ты начала

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

Цитата(BRE @ 18.11.2011, 15:38) *
есть железки у которых нет ОС и нет такого понятия как модуль ядра в принципе

это ты МНЕ рассказываешь? :D я программировала всё от микрочипов до FPGA, причём на низком уровне. мой отладчик - высокочастотный осциллограф, а документация - доки на железо и схемы :) ясен пень, что в подавляющем числе случаев никакой оси нет. либо она разрабатывается производителем или сторонней компанией, отдельно от самого контроллера и часто вовсе не бесплатно. смотря какая задача, смотря какой чип, смотря что ты собрался делать. просто часто сам пишешь свой простой загрузчик и подобие мелкого ядра. так удобнее: девайс не должен выходить из строя, должна быть возможность обновления микрокода и юзер должен иметь возможность его прошивать. а кто его будет прошивать? это либо ставить ещё один контроллер (который, опять же, надо программировать!), либо писать загрузчик, который жёстко сидит в защищённой области и уже сам грузит что-то с флэшки. мы делаем когда как: если триггеров в запасе дофига - тогда проще сделать загрузчик. а если ресурс ограничен и конфигурация какая-то сложная, где много DSP-шек на одной плате шьются параллельно - можно и отдельно чип поставить. и вот я пишу то самое программное обеспечение. я программист отдела аппаратного обеспечения :)
BRE
Цитата(Iron Bug @ 18.11.2011, 13:57) *
ыхх... сложно говорить с юзерами верхнего уровня! :)

Это ты про меня? :)

Цитата(Iron Bug @ 18.11.2011, 13:57) *
хардварная атомарность не имеет отношения к вводу-выводу.

Какая хардварная атомарность?
Мы говорим о реализации атомарных операций на пользовательском уровне... Если говорить про архитектуру x86, то они довольно просто реализуются на пользовательском уровне с использованием ассемблера.

Инструкция
mov eax, ebx

а точнее ее опкод, это четкая команда железке под названием процессор загрузить содержимое внутреннего регистра ebx в регистр eax. Это можно рассматривать как обращение к железу! :)
Iron Bug
Цитата(BRE @ 18.11.2011, 16:21) *
загрузить содержимое внутреннего регистра ebx в регистр eax

в регистре - дофига битов. и вот именно чтобы их все загрузить "одновременно" (на самом деле, это не так, но синхронизация на шине позволяет получать данные со всех битов сразу) и нужна аппаратная атомарность. а если идёт обмен по шине, например, с памятью? читаем блок данных с DDR или с SATA: это асинхронный процесс передачи некой последовательности битов. и чтобы было понятно, что адрес выставлен и бёрст пошёл, нужна атомарность на хардварном уровне.
а в некоторых классах чипов вообще нет такого понятия, как байт или слово. есть максимальная разрядность шины. и всё.
так что поддержка некоторых атомарных операций там очень важна.
BRE
Цитата(Iron Bug @ 18.11.2011, 14:26) *
Цитата(BRE @ 18.11.2011, 16:21) *
загрузить содержимое внутреннего регистра ebx в регистр eax

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

Хорошо и что это опровергает в моих словах? :)
Выполнение инструкции процессора это не обращение к железу?
Или это делает невозможным реализацию атомарных операций?
О чем спорим? :)
Iron Bug
Цитата(BRE @ 18.11.2011, 16:40) *
О чем спорим?

я не спорю. я просто уточняю понятие атомарности :)
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.