| Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | vladserge | |
| Дата: | 14.10.04 06:47 | |
| Оценка: | 2 (1) | |
| Привет всем! Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него). например так
во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации. В .NET кое что на эту тему появилось, я про Interlocked, но вырозительности и прозрачности использования нет зацените сами
понятно, что найдуться чайники которые начнут внутрь атомарного кода пихать длительные операции приводя к завесалову всей системы. Но с этим можно бороться, например подразумевая что НЕпереключения потоков внутри атомарного кода происходит только в контексте приложения, а не всей системы. Таким образом если некто напишет ахинею типа
то зависнет только это приложение. Просто делюсь соображениями, возможно что я не одинок.... или это велосипед и я чего то незнаю. Обсудим ? С Уважением Сергей Чикирев | |
| Re: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 14.10.04 07:42 | |
| Оценка: | 22 (2) | |
| Здравствуйте, vladserge, Вы писали: V> или это велосипед и я чего то незнаю В ОО языке Active Oberon для программирования параллельных вычислений существует всего три ключевых слова ACTIVE, EXCLUSIVE и AWAIT. Ключевое слово ACTIVE используется для того чтобы различать активные объекты от обычных-пассивных объектов. Для обеспечения описанной Вами "атомарности" используются другие два слова EXCLUSIVE и AWAIT. EXCLUSIVE — как раз и гарантирует, что указанное действие должно выполниться полностью, до того как кто-то другой захочет выполнить это же самое действие, вот Вам и "атомарность":
AWAIT(Condition: BOOLEAN) — приостанавливает активность (активность = поток/процесс активного объекта) до тех пор пока не будет выполнено условие Condition. Вот пример пассивного объекта, доступ к которому потокобезопасен:
http://bluebottle.ethz.ch/languagereport/index.html http://www.oberon.ethz.ch/active/ http://www.oberon.ethz.ch/native/aos/ http://www.cs.inf.ethz.ch/~muller/ http://bluebottle.ethz.ch/ http://www.zonnon.ethz.ch/ |
| Re: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | sereda | http://igorsereda.moikrug.ru |
| Дата: | 14.10.04 08:22 | |
| Оценка: | +1 | |
| Здравствуйте, vladserge, Вы писали: V>Привет всем! V>Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него). Видите ли, переключение потока — это системная операция, и хорошо бы, чтобы язык высокого уровня не имел к ней доступа. Это все равно что требовать, чтобы вот на этом участке кода процессор не переключался на другой процесс. Я полагаю, Вы хотите достигнуть атомарности операции. Переключение потоков здесь ни при чем. Просто надо обеспечить условия для того, чтобы другой поток не "увидел" результаты вашей операции, пока она до конца не выполнилась. В Java для этого используются мониторы и ключевое слово synchronized. Переписывая Ваш пример:
При заходе в блок synchronized монитор, ассоциированный с объектом lock, включается, и другие потоки не смогут войти в блок с таким же монитором, пока тот не освободится. По моему, очень удобная и высокоуровневая конструкция, учитывая дополнительные возможности Java с ключевым словом synchronized. |
| Re: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WolfHound rsdn | |
| Дата: | 14.10.04 09:02 | |
| Оценка: | +1 | |
| Здравствуйте, vladserge, Вы писали: V>В .NET кое что на эту тему появилось, я про Interlocked, но вырозительности и прозрачности использования нет V>зацените сами Ну это появилось не в .НЕТ, а гораздо раньше
V>понятно, что найдуться чайники которые начнут внутрь атомарного кода пихать длительные операции приводя к завесалову всей системы. Но с этим можно бороться, например подразумевая что НЕпереключения потоков внутри атомарного кода происходит только в контексте приложения, а не всей системы. Таким образом если некто напишет ахинею типа Гм. ИМХО мысль не плохая. Но ИМХО придется вводить поддержку на уровне операционной системы. Тут есть форум в котором можно задать вопросы ребятам из Майкрософт... спроси у них. ... << RSDN@Home 1.1.4 rev. 185 >> Пусть это будет просто: | просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[2]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WolfHound rsdn | |
| Дата: | 14.10.04 09:02 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>EXCLUSIVE — как раз и гарантирует, что указанное действие должно выполниться полностью, до того как кто-то другой захочет выполнить это же самое действие, вот Вам и "атомарность": СГ>
Если да то что мешает другому потоку обратиться к рассогласованым x, y? ... << RSDN@Home 1.1.4 rev. 185 >> Пусть это будет просто: | просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[2]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | vladserge | |
| Дата: | 14.10.04 09:16 |
| Здравствуйте, sereda, Вы писали: S>Здравствуйте, vladserge, Вы писали: V>>Привет всем! V>>Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него). S>Видите ли, переключение потока — это системная операция, и хорошо бы, чтобы язык высокого уровня не имел к ней доступа. Это все равно что требовать, чтобы вот на этом участке кода процессор не переключался на другой процесс. именно этого и хочется, я ж ясно выразился, как впрочем и для чего. S>Я полагаю, Вы хотите достигнуть атомарности операции. Переключение потоков здесь ни при чем. Просто надо обеспечить условия для того, чтобы другой поток не "увидел" результаты вашей операции, пока она до конца не выполнилась. дивно, а не проще ли систнмному диспетчеру процессов обнаружить что он внутри атомарного блока и не деактивировать текущий процесс и переключаться на доругой. Это ОЧЕНЬ ДОРОГО !!!!!! S>В Java для этого используются мониторы и ключевое слово synchronized. нужно будет записать, а то забуду S>По моему, очень удобная и высокоуровневая конструкция, учитывая дополнительные возможности Java с ключевым словом synchronized. Спасибо за ответ, но на будущее просьба, до конца читать пост на который Вы отвечаете. Я ж ведь не графоман какой, то и когда пишу буквально во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации. то это я делаю специально для Вас. С Уважением Сергей Чикирев | |
| Re[2]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | vladserge | |
| Дата: | 14.10.04 09:22 |
| Здравствуйте, WolfHound, Вы писали: WH>Здравствуйте, vladserge, Вы писали: V>>В .NET кое что на эту тему появилось, я про Interlocked, но вырозительности и прозрачности использования нет V>>зацените сами WH>Ну это появилось не в .НЕТ, а гораздо раньше Ошибся хотел написать В например .NET кое что на эту тему есть далее по тексту.... V>>Гм. ИМХО мысль не плохая. Но ИМХО придется вводить поддержку на уровне операционной системы. Ну я тут не о трудностях, а об удобстве и необходимости фичи рассуждаю. V>>Тут есть форум в котором можно задать вопросы ребятам из Майкрософт... спроси у них. Пока ясовсем неуверен, что это кому нибудь, кроме меня может быть интересно. а там .... будем посмотреть. PS спасибо за ответ С Уважением Сергей Чикирев | |
| Re: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 14.10.04 09:30 | |
| Оценка: | 15 (4) | |
| Здравствуйте, vladserge, Вы писали: V>во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации. ... но, в отличие от мониторов/крит.секций, не гарантирует целостности. Пример:
Запустили оба потока. Первый: взял x... (и был вытеснен) Второй: обменял x,y Первый: взял y и напечатал. Что мы видим? Правильно: 1,1 Поскольку мониторы очень и очень распространены, специально для этого любая нормальная ОС содержит легковесные средства их реализации. Например, под виндоузом есть два мутекса — "дорогой" HMUTEX и "дешёвый" CRITICAL_SECTION. Первый — это объект ядра, все операции над ним требуют проваливания в нулевое кольцо. Второй — объект пользователя, сделанный чуть ли не на InterlockedExchange() / Sleep(). Перекуём баги на фичи! |
| Re[3]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | sereda | http://igorsereda.moikrug.ru |
| Дата: | 14.10.04 09:36 |
| Здравствуйте, vladserge, Вы писали: V>Спасибо за ответ, но на будущее просьба, до конца читать пост на который Вы отвечаете. Я ж ведь не графоман какой, то и когда пишу буквально V>во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации. V>то это я делаю специально для Вас. Спасибо Вам за то, что Вы делаете специально для меня. Я прочитал Ваш пост еще раз внимательно. Конечно, очевидно, что в цитируемой Вами фразе Вы имели в виду и synchronized в Java. Покорнейше прошу прощения за то, что не заметил сразу, и что купился на предложение обсудить вопрос. По теме. Если вы хотите сэкономить на context switching'e, то надо от языков требовать поддержки атомарных команд процессора вроде TestAndSet. Блокировать context switching грубой силой — это значит рисковать из-за ошибок нарушить работу не только приложения, но и всей операционки. Не думаю, что этот риск оправдан соображениями производительности. |
| Re[2]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | vladserge | |
| Дата: | 14.10.04 09:49 |
| Здравствуйте, Кодт, Вы писали: К>Здравствуйте, vladserge, Вы писали: V>>во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации. К>... но, в отличие от мониторов/крит.секций, не гарантирует целостности. К>Пример: К>
К>Запустили оба потока. К>Первый: взял x... (и был вытеснен) К>Второй: обменял x,y К>Первый: взял y и напечатал. К>Что мы видим? Правильно: 1,1 Ну так не честно исправить его достаточно несложно
или, если уж к примеру printf — длительная операция.
К>Поскольку мониторы очень и очень распространены, специально для этого любая нормальная ОС содержит легковесные средства их реализации. При любых самых разлегковестных средствах переключение потока на несколько тактов позже жестко запланированого выиграет (в смысле наклодных расходов). и вот еще одна деталь, у этой модели небывает дедлоков С Уважением Сергей Чикирев | |
| Re[4]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | vladserge | |
| Дата: | 14.10.04 09:58 |
| Здравствуйте, sereda, Вы писали: S>Здравствуйте, vladserge, Вы писали: V>>Спасибо за ответ, но на будущее просьба, до конца читать пост на который Вы отвечаете. Я ж ведь не графоман какой, то и когда пишу буквально V>>во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации. V>>то это я делаю специально для Вас. S>Спасибо Вам за то, что Вы делаете специально для меня. Я прочитал Ваш пост еще раз внимательно. Конечно, очевидно, что в цитируемой Вами фразе Вы имели в виду и synchronized в Java. Покорнейше прошу прощения за то, что не заметил сразу, и что купился на предложение обсудить вопрос. S>По теме. Если вы хотите сэкономить на context switching'e, то надо от языков требовать поддержки атомарных команд процессора вроде TestAndSet. Блокировать context switching грубой силой — это значит рисковать из-за ошибок нарушить работу не только приложения, но и всей операционки. Не думаю, что этот риск оправдан соображениями производительности. Да простят меня модераторы за частое самоцетирование, ну а что делать? понятно, что найдуться чайники которые начнут внутрь атомарного кода пихать длительные операции приводя к завесалову всей системы. Но с этим можно бороться, например подразумевая что НЕпереключения потоков внутри атомарного кода происходит только в контексте приложения, а не всей системы. А по поводу возможностей и "рисковать из-за ошибок нарушить работу не только приложения, но и всей операционки" откомпилируйте и запустите
понятно, что спички детям не игрушка. С Уважением Сергей Чикирев | |
| Re[3]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WolfHound rsdn | |
| Дата: | 14.10.04 10:09 |
| Здравствуйте, vladserge, Вы писали: V>Ну я тут не о трудностях, а об удобстве и необходимости фичи рассуждаю. Дело в том что если обсуждать фичу то нужно выяснить соотношение необходимость/цена. И в этом свете нужно обсудить сложности. V>Пока ясовсем неуверен, что это кому нибудь, кроме меня может быть интересно. а там .... будем посмотреть. Тут надо подумать о целесообразности этого. Ведь в сущьности это всеголишь глобальный(в приделах процесса)мутекс. Хотя если производительность этого мутекса будет сравнима с Interlocked функциями и этот мутекс будет всегда инициализирован то это может быть полезно. ... << RSDN@Home 1.1.4 rev. 185 >> Пусть это будет просто: | просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[4]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | vladserge | |
| Дата: | 14.10.04 10:25 |
| Здравствуйте, WolfHound, Вы писали: WH>Здравствуйте, vladserge, Вы писали: V>>Ну я тут не о трудностях, а об удобстве и необходимости фичи рассуждаю. WH>Дело в том что если обсуждать фичу то нужно выяснить соотношение необходимость/цена. И в этом свете нужно обсудить сложности. Мне всеже кажется для начала нужно понять насколько это "фкусно", прежде чем стоять за этим в очередь. V>>Пока ясовсем неуверен, что это кому нибудь, кроме меня может быть интересно. а там .... будем посмотреть. WH>Тут надо подумать о целесообразности этого. Ведь в сущьности это всеголишь глобальный(в приделах процесса)мутекс. мутекс. WH>Хотя если производительность этого мутекса будет сравнима с Interlocked функциями и этот мутекс будет всегда инициализирован то это может быть полезно. ничего не понимаю С Уважением Сергей Чикирев | |
| Re: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | GlebZ | |
| Дата: | 14.10.04 10:30 |
| Здравствуйте, vladserge, Вы писали: Товарищ, вы отстаете от моды. Сейчас модно защищать объекты, а не просто куски кода. Наглядный пример из NET:
В результате, есть ГАРАНТИЯ правильной синхронизации объекта как внутри, так и снаружи. Защищаются именно данные а не действия над ним (и ессно в разумной степени). Защита какой-то отдельной процедуры практически никогда не нужно, и самое главное вредно. У тебя нет никакой гарантии, что при дальнейшем развитии не будет написана другая процедура работающая с этими данными. Была одна какая-то интересная книжка Рихтера (не помню названия, давно читал), где он примерно описывал работу объектов синхронизации для Win API. С уважением, Gleb. |
| Re[3]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 14.10.04 10:39 |
| Здравствуйте, vladserge, Вы писали: V>Ну так не честно V>исправить его достаточно несложно Ну и что получаем? Всё тот же монитор. К>>Поскольку мониторы очень и очень распространены, специально для этого любая нормальная ОС содержит легковесные средства их реализации. V>При любых самых разлегковестных средствах переключение потока на несколько тактов позже жестко запланированого выиграет (в смысле наклодных расходов). и вот еще одна деталь, у этой модели небывает дедлоков Ха! Если хочешь избежать дедлоков — заведи единственный мутекс в программе. Эффект будет абсолютно таким же, как с длинными атомарными операциями. Собственно, Interlocked операции и используют мутекс, только аппаратный. Перекуём баги на фичи! |
| Re[5]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 14.10.04 10:45 |
| Здравствуйте, vladserge, Вы писали: WH>>Тут надо подумать о целесообразности этого. Ведь в сущьности это всеголишь глобальный(в приделах процесса)мутекс. V>мутекс. Именно мутекс как абстракция многозадачного программирования. Какая именно реализация этого мутекса — на HMUTEX, на CRITICAL_SECTION, на семафорах — это уже нюансы. (Мне однажды пришлось реализовывать на трубках — pipe — потому что API VxWorks не поддерживает групповых операций над иными синхрообъектами). Перекуём баги на фичи! |
| Re: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sinclair rsdn | http://www.parallels.com/automation/operations/ |
| Дата: | 14.10.04 10:48 | |
| Оценка: | 1 (1) +1 | |
| Re[2]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | vladserge | |
| Дата: | 14.10.04 13:22 |
| Здравствуйте, Sinclair, Вы писали: S>Здравствуйте, vladserge, Вы писали: V>>Привет всем! V>>Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него). S>А ты уверен, что возникает именно такая необходимость? Дело в том, что обычно проблемы одновременного доступа относятся скорее не к атомарности какого-то фрагмента кода, а к атомарности какого-то фрагмента данных. И именно для защиты данных вводятся всякие примитивы синхронизации. Запрет на исполнение вообще любого кода во время исполнения твоего фрагмента просадит производительность. Это почему же?????????? А я утверждаю что все произойдет с точностью до НАОБОРОТ. Производительность возрастет и вот почему. Вместо выполнения совокупности дорогостоящих процедур синхронизации, код просто эксклюзивно продолжает выполняться в плоть до выхода из атомарной секции. Порошу заметить ВЫПОЛНЯТЬСЯ, не блокироваться, а выполняться! В каком месте будет падение производительности ???? С Уважением Сергей Чикирев | |
| Re[3]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Merle rsdn | http://rsdn.ru |
| Дата: | 14.10.04 13:57 |
| Здравствуйте, vladserge, Вы писали: V>Производительность возрастет и вот почему. Вместо выполнения совокупности дорогостоящих процедур синхронизации, код просто эксклюзивно продолжает выполняться в плоть до выхода из атомарной секции. Порошу заметить ВЫПОЛНЯТЬСЯ, не блокироваться, а выполняться! Это получается уже кооперативная многозадачность, а не вытесняющая. И приводит это к тому, что если твой код навернулся внутри критической секции, не важно по какой причине, расхлебывать будет вся система. Последствия подобного поддхода очень хорошо были видны на примере win16, там делалось ровно так как ты описываешь... Правда и у вытесняющей многозадачности, с блокировкой данных, есть свои подводные камни ввиде тогоже Convoy Effect'а, но с ними более-менее научились бороться... ... [ RSDN@Home 1.1.4 revision 142 ] Мы уже победили, просто это еще не так заметно... |
| P. S. | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Merle rsdn | http://rsdn.ru |
| Дата: | 14.10.04 14:01 | |
| Оценка: | 35 (2) | |
| Кстати, то, что ты называешь "атомарность", скорее стоит назвать "сериализуемость" или "изолированность"... Все-таки под атомарностью обычно понимают немного другое. Атомарность — это если твой код либо выполняется целиком, либо не выполняется вообще. И мьютексы с семафорами и прочими блокировками здесь не спасут, если кусок кода навернется в середине выполнения, то об откате надо заботиться отдельно. ... [ RSDN@Home 1.1.4 revision 142 ] Мы уже победили, просто это еще не так заметно... |
| Re[2]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | GlebZ | |
| Дата: | 14.10.04 14:05 |
| Здравствуйте, WolfHound, Вы писали: V>>понятно, что найдуться чайники которые начнут внутрь атомарного кода пихать длительные операции приводя к завесалову всей системы. Но с этим можно бороться, например подразумевая что НЕпереключения потоков внутри атомарного кода происходит только в контексте приложения, а не всей системы. Таким образом если некто напишет ахинею типа WH>Гм. ИМХО мысль не плохая. Но ИМХО придется вводить поддержку на уровне операционной системы. WH>Тут есть форум в котором можно задать вопросы ребятам из Майкрософт... спроси у них. Так есть в Win API такое средство, называется CRITICAL_SECTION. У меня появилось смутное сомнение, что здесь везде подразумевается Java, и, соответвенно, ведется разговор слепого с глухим. С уважением, Gleb. |
| Re[4]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 14.10.04 16:20 |
| Здравствуйте, Merle, Вы писали: M>Правда и у вытесняющей многозадачности, с блокировкой данных, есть свои подводные камни ввиде тогоже Convoy Effect'а, но с ними более-менее научились бороться... А что такое convoy effect? Перекуём баги на фичи! |
| Re[5]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Merle rsdn | http://rsdn.ru |
| Дата: | 14.10.04 20:10 | |
| Оценка: | 40 (1) | |
| Здравствуйте, Кодт, Вы писали: К>А что такое convoy effect? Кажется правильнее все-таки Convoy Phenomena, а может и то и то верно, убей байт — не помню, но не важно... Суть явления в следующем: допустим какой-то поток блокировал некий ресурс и давай его всячески пользовать, но тут его квант времени истек, а закончить работу он не успел. Пришел диспетчер потоков и передал управление другому потоку, которому так же нужен этот же ресурс. Но этот другой поток захватить этот ресурс уже не может, так как предыдущий блокировку снять не успел, и все отпущенное время проводит в бесцельном ожидании... И все остальные потоки, которым нужен этот ресурс, так же тихо курят, пока управление по цепочке опять не перейдет к потоку владельцу ресурса... И так продолжается до тех пор, пока не снимется блокировка. В пинципе напоминает дедлок, но отличается от него в лучшую сторону тем, что Convoy может сам рассосатья, когда спадает нагрузка, правда от этого не на много легче. Метод борьбы с этим явлением довольно прост, надо засатвить поток, при обнаружения того, что нужный ресурс уже заблокирован кем-то другим, самому передавать управление дальше по цепочке, не дожидаясь окончания своего кванта. Вообще классической по данному вопросу считается статья Дж. Грэя со товарищи, "The Convoy Phenomena", аж 79 года рождения (статья), но в открытом доступе мне ее, к сожалению, найти не удалось.. (Если интересно, можно Синклера потерзать, может быть у него остался аккаунт на http://portal.acm.org, там она есть) ... [RSDN@Home 1.1.4 revision 142] Мы уже победили, просто это еще не так заметно... |
| Re: P. S. | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | vladserge | |
| Дата: | 15.10.04 00:37 |
| Здравствуйте, Merle, Вы писали: M>Кстати, то, что ты называешь "атомарность", скорее стоит назвать "сериализуемость" или "изолированность"... Все-таки под атомарностью обычно понимают немного другое. Я подразумеваю только то что подразумевает микрософт описывая Interlocked Class и далее
Когда Вы писали "Атомарность — это если твой код либо выполняется целиком, либо не выполняется вообще." Вы, вероятно имели ввиду другое понятие — трансакционность.Трансации именно так себя и ведут. Именно трансации даже если они уже начались обнаружив невозможность дальнейшего выполнения обязаны откатить все на исходную позицию. Я же об этом ни слова не говорил. цитирую еще один ваш довод M>Это получается уже кооперативная многозадачность, а не вытесняющая. И приводит это к тому, что если твой код M>навернулся внутри критической секции, не важно по какой причине, расхлебывать будет вся система. ничего не получается даже рядом не стояло. да простят меня модераторы вынужден себя процитировать еще раз понятно, что найдуться чайники которые начнут внутрь атомарного кода пихать длительные операции приводя к завесалову всей системы. Но с этим можно бороться, например подразумевая что НЕпереключения потоков внутри атомарного кода происходит только в контексте приложения, а не всей системы. млин все начинают лезть в такие дебри, вспоминать странные аналогии, а просто прочитать до конца сил ненаходят откровенно говоря думал что получится более конструктивное обсуждения с попытками поняв мною написанное приложить к задачам сегодняшнего дня, взвесить плюсы и минусы. именно понимание того что могут возникнуть ИНЫЕ взгляды на предложенный механизм, сподвигнули меня написать об этом. С Уважением Сергей Чикирев | |
| Re[3]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sinclair rsdn | http://www.parallels.com/automation/operations/ |
| Дата: | 15.10.04 03:41 | |
| Оценка: | 14 (1) | |
| Re[6]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 15.10.04 07:09 |
| Здравствуйте, Merle, Вы писали: M>Метод борьбы с этим явлением довольно прост, надо засатвить поток, при обнаружения того, что нужный ресурс уже заблокирован кем-то другим, самому передавать управление дальше по цепочке, не дожидаясь окончания своего кванта. Дык, вроде бы все так и делают, кроме отморозков. Любая функция захвата ресурса с ненулевым таймаутом приводит к переключению. А заниматься, простите, онанизмом вида
нафиг надо? Перекуём баги на фичи! |
| Re[6]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 15.10.04 07:13 |
| Здравствуйте, Merle, Вы писали: M>(Если интересно, можно Синклера потерзать, может быть у него остался аккаунт на http://portal.acm.org, там она есть) Вот линк на статью, теперь дело за аккаунтом... The convoy phenomenon Mike Blasgen, Jim Gray, Mike Mitoma, Tom Price April 1979 ACM SIGOPS Operating Systems Review, Volume 13 Issue 2 Перекуём баги на фичи! |
| Re[2]: P. S. | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Merle rsdn | http://rsdn.ru |
| Дата: | 15.10.04 07:13 |
| Здравствуйте, vladserge, Вы писали: V>Я подразумеваю только то что подразумевает микрософт описывая Interlocked Class Не очень понимаю, что подразумевает под этим MS, главное чтобы мы подразумевали под этим одно и тоже... V>Когда Вы писали "Атомарность — это если твой код либо выполняется целиком, либо не выполняется вообще." V>Вы, вероятно имели ввиду другое понятие — трансакционность. Нет, я имел ввиду именно атомарность. V>Трансации именно так себя и ведут. Правильно, а теперь давайте внимательно посмотрим, что такое транзакция. По определению транзакция это группа операций, которая обладает свойствами ACID — Атомарности (Atomicity), Согласованности(Concistency), Изолированности (Isolation), Устойчивости (Durability) V>Именно трансации даже если они уже начались обнаружив невозможность дальнейшего выполнения обязаны откатить все на исходную позицию. Правильно, но сделать они обязаны не сами по себе, а по той причине, что одним из свойств транзакций является атомарность, (помимо изолированности, что является отдельной головной болью). V>ничего не получается даже рядом не стояло. Стояло, это именно оно и есть. V>понятно, что найдуться чайники которые начнут внутрь атомарного кода пихать длительные операции приводя к завесалову всей системы. Но с этим можно бороться, например подразумевая что НЕпереключения потоков внутри атомарного кода происходит только в контексте приложения, а не всей системы. Разница невелика. Под системой можно понимать и одно приложение. Те же древние винды были, по сути, всего лишь приложением, и кому от этого было легче? Плюс, как совершенно верно заметил Синклер, реализация подобного шедулера сама по себе будет довольно накладной. V>млин все начинают лезть в такие дебри, вспоминать странные аналогии, а просто прочитать до конца сил ненаходят Спокуха на лице... Все все внимательно читают и прекрасно понимают. V> именно понимание того что могут возникнуть ИНЫЕ взгляды на предложенный механизм, сподвигнули меня написать об этом. Вот они иные взгляды и есть, кто ж виноват, что они не всегда устраивают... ... [ RSDN@Home 1.1.4 revision 142 ] Мы уже победили, просто это еще не так заметно... |
| Re[3]: Не волнуйтесь, всё чики-пуки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 15.10.04 07:21 |
| Здравствуйте, WolfHound, Вы писали: WH>Если да то что мешает другому потоку обратиться к рассогласованым x, y? Не забывайте, что в Active Oberon нет таких понятий как поток или процесс, а есть понятие активности (активного объекта). Переменные x и y — есть приватные переменнные объекта и изменять их можно только посредством методов объекта, а эти методы программист должен пометить директивой {EXCLUSIVE}, и все чики-пуки!
|
| Re: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | LaptevVV rsdn | http://vk.com/id59893040 |
| Дата: | 15.10.04 07:24 |
| Здравствуйте, vladserge, Вы писали: V>Привет всем! V>Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него). V>Просто делюсь соображениями, возможно что я не одинок.... или это велосипед и я чего то незнаю. Обсудим ? В Яве можно объявить метод sinchronized — имхо как раз то самое. Наши программисты — самые программистые программисты в мире! | |
| Re[3]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 15.10.04 07:27 |
| Здравствуйте, vladserge, Вы писали: V>я утверждаю что все произойдет с точностью до НАОБОРОТ. V>Производительность возрастет и вот почему. Вместо выполнения совокупности дорогостоящих процедур синхронизации, код просто эксклюзивно продолжает выполняться в плоть до выхода из атомарной секции. Порошу заметить ВЫПОЛНЯТЬСЯ, не блокироваться, а выполняться! Вы совершенно правы. Операционная система Aos Bluebotle написанная на языке Active Oberon демонстрирует производительность превышающую производительность ОС Linux в несколько раз. http://www.rsdn.ru/Forum/Message.aspx?mid=853268&only=1 Автор: Сергей Губанов Дата: 15.10.04 Сама Aos: http://bluebottle.ethz.ch/ |
| Re[7]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Merle rsdn | http://rsdn.ru |
| Дата: | 15.10.04 08:06 | |
| Оценка: | 77 (6) | |
| Здравствуйте, Кодт, Вы писали: К>Дык, вроде бы все так и делают, кроме отморозков. Любая функция захвата ресурса с ненулевым таймаутом приводит к переключению. А заниматься, простите, онанизмом вида К>
К>нафиг надо? Ну я там не совсем верно объяснил... Проблема в том, что даже стандартный, на первый взгляд вполне безопасный подход, со спинлоками, способен привести к конвою. Допустим есть ресурс, который захватывается и освобождается много раз в течении кванта потока. Если переключение контекста произошло в тот момент, когда ресурс захвачен, другие потоки, бесполезно покрутившись на спинлоке, впадают в спячку, поставив себя в очередь. Если же переключение контекста произошло в тот момент, когда ресурс свободен, то ресурс оказывается немедленно захвачен другим потоком, а первоначальный поток, при попытке опять воспользоваться ресурсом, попадает на ожидание и оказывается в конце очереди. Со временем очередь только растет и конвой не рассасывается до возникновения какой-нибудь нерегулярности. И дальше по кругу — ни один поток не может удержать ресурс дольше небольшой доли кванта (квант / сколько раз за квант ресурс захватывается потоком). Вот воркэраунд от MS по борьбе с конвоями:
В данном случае, нарвавшись на блокировку поток не ставит себя в очередь, а явно передает управление дальше по цепочке. Как только исчезает очередь, конвой рассасывается, будет серия быстрых переключений контекста, нопосле освобождения ресурса никто его немедленно не захватывает, поэтому текущий поток спокойно может повторно им повладеть. ... [ RSDN@Home 1.1.4 revision 142 ] Мы уже победили, просто это еще не так заметно... |
| Re: P. S. | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 15.10.04 08:12 |
| Здравствуйте, Merle, Вы писали: M>Кстати, то, что ты называешь "атомарность", скорее стоит назвать "сериализуемость" или "изолированность"... В Active Oberon это называется "эксклюзивность" {EXCLUSIVE} |
| Re[6]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sinclair rsdn | http://www.parallels.com/automation/operations/ |
| Дата: | 15.10.04 08:42 |
| Здравствуйте, Merle, Вы писали: M>Вообще классической по данному вопросу считается статья Дж. Грэя со товарищи, "The Convoy Phenomena", аж 79 года рождения (статья), но в открытом доступе мне ее, к сожалению, найти не удалось.. M>(Если интересно, можно Синклера потерзать, может быть у него остался аккаунт на http://portal.acm.org, там она есть) Не, мне его закрыли за неуплату ... << RSDN@Home 1.1.4 beta 3 rev. 185>> Уйдемте отсюда, Румата! У вас слишком богатые погреба. | |
| Re[4]: Не волнуйтесь, всё чики-пуки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 15.10.04 08:52 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>блок выполняется "целиком" и "сразу". P. S. Кстати, чтобы не загромождать текст программы словами EXCLUSIVE, некоторые операции гарантированно эксклюзивны. Например, операция n := n + 1; записанная как INC(n); является эксклюзивной, то есть вместо
можно просто написать
ну и т.п. для других элементарных операций... |
| Re[2]: P. S. | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Kluev | |
| Дата: | 15.10.04 09:52 | |
| Оценка: | 1 (1) | |
| Здравствуйте, vladserge, Вы писали: Это будет очень хорошо работать в системах с одним процессором, где два треда просто не могут исполнятся одновременно, здесь действително будет очень круто не переключаемся пока не вышли из atomic. Однако в многопроцессорных системах будут траблы. |
| Re[3]: P. S. | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 15.10.04 10:05 | |
| Оценка: | ![]() | |
| Здравствуйте, Kluev, Вы писали: K>Здравствуйте, vladserge, Вы писали: K>Это будет очень хорошо работать в системах с одним процессором, где два треда просто не могут исполнятся одновременно, здесь действително будет очень круто не переключаемся пока не вышли из atomic. Однако в многопроцессорных системах будут траблы. Эти траблы могут быть в не объектно ориентированных системах. В объектно ориентированных их не будет. Так, например, в Active Oberon таких траблов не возникает, поскольку секция EXCLUSIVE привязана к конкретной активности — активному объекту, остальные активности не имеющие к первой никакого отношения, разумеется, продолжают исполняться на других процессорах как ни в чем не бывало. |
| Re[4]: P. S. | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Kluev | |
| Дата: | 15.10.04 10:30 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Kluev, Вы писали: K>>Здравствуйте, vladserge, Вы писали: K>>Это будет очень хорошо работать в системах с одним процессором, где два треда просто не могут исполнятся одновременно, здесь действително будет очень круто не переключаемся пока не вышли из atomic. Однако в многопроцессорных системах будут траблы. СГ>Эти траблы могут быть в не объектно ориентированных системах. В объектно ориентированных их не будет. Так, например, в Active Oberon таких траблов не возникает, поскольку секция EXCLUSIVE привязана к конкретной активности — активному объекту, остальные активности не имеющие к первой никакого отношения, разумеется, продолжают исполняться на других процессорах как ни в чем не бывало. Это будет работать только если вы каждому акивному обьекту дадите по процессору. В противном случае траблы. |
| Re[5]: P. S. | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Nick_ | |
| Дата: | 15.10.04 11:43 |
| Здравствуйте, Kluev, Вы писали: K>Это будет работать только если вы каждому акивному обьекту дадите по процессору. В противном случае траблы. Что мешает это сделать? |
| Re[3]: P. S. | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | vladserge | |
| Дата: | 15.10.04 12:14 |
| Здравствуйте, Kluev, Вы писали: K>Здравствуйте, vladserge, Вы писали: K>Это будет очень хорошо работать в системах с одним процессором, где два треда просто не могут исполнятся одновременно, здесь действително будет очень круто не переключаемся пока не вышли из atomic. Однако в многопроцессорных системах будут траблы. К сожелению, ничего сколь нибудь компетентно на тему мультипроцессорности сказать не могу, С Уважением Сергей Чикирев | |
| Re[4]: P. S. | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 15.10.04 12:54 |
| Здравствуйте, vladserge, Вы писали: V>К сожелению, ничего сколь нибудь компетентно на тему мультипроцессорности сказать не могу, О чем и речь. Ексклюзивная секция выпоняется целиком. И толковые ссылочки есть: Вот пожалуйста, уже готовенькая операционка: http://bluebottle.ethz.ch/ А вот ее автор: http://www.cs.inf.ethz.ch/~muller/ А вот его докторская диссера посвященная этому вопросу: http://e-collection.ethbib.ethz.ch/cgi-bin/show.pl?type=diss&nr=14755 |
| Re[5]: P. S. | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 15.10.04 13:09 |
| Здравствуйте, Kluev, Вы писали: K>Это будет работать только если вы каждому акивному обьекту дадите по процессору. В противном случае траблы. В каждый отдельно взятый момент времени, по настоящему "активны" лишь столько объектов, сколько есть в наличии процессоров. А остальные — ждут своего time slice. Так в чем, собственно, состоит Ваше утверждение? Если активных объектов будет больше чем процессоров, то будут траблы? По крайней мере Питеру Мюллеру, создателю Aos, предрекаемые Вами гипотетические траблы преодолеть как-то удалось. |
| Re[5]: P. S. | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | vladserge | |
| Дата: | 16.10.04 04:39 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, vladserge, Вы писали: V>>К сожелению, ничего сколь нибудь компетентно на тему мультипроцессорности сказать не могу, СГ>О чем и речь. Ексклюзивная секция выпоняется целиком. И толковые ссылочки есть: СГ>Вот пожалуйста, уже готовенькая операционка: http://bluebottle.ethz.ch/ СГ>А вот ее автор: http://www.cs.inf.ethz.ch/~muller/ СГ>А вот его докторская диссера посвященная этому вопросу: http://e-collection.ethbib.ethz.ch/cgi-bin/show.pl?type=diss&nr=14755 Спасибо С Уважением Сергей Чикирев | |
| Re[6]: P. S. | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 17.10.04 01:39 |
| Здравствуйте, Сергей Губанов, Вы писали: K>>Это будет работать только если вы каждому акивному обьекту дадите по процессору. В противном случае траблы. СГ>В каждый отдельно взятый момент времени, по настоящему "активны" лишь столько объектов, сколько есть в наличии процессоров. Это 100% коррелирует с моделью вытесняющей многозадачности в "обычной" операционной системе. Там тоже в один момент времени активно столько потоков, сколько имеется процессоров в компьютере. Остальные ждут timeslice. СГ> А остальные — ждут своего time slice. Так в чем, собственно, состоит Ваше утверждение? Если активных объектов будет больше чем процессоров, то будут траблы? По крайней мере Питеру Мюллеру, создателю Aos, предрекаемые Вами гипотетические траблы преодолеть как-то удалось. Никаких там чудес нет. Во всяком случае, если бы удалось, то в контексте Aos вообще не упоминалось бы понятий, связанных с синхронизацией. Как был фон-Нейман, так и остался. Как была необходимость разруливания потоков при обращении к ресурсам, так она и осталась. ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Ну никаких тут чудес нет и быть не может | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 17.10.04 03:29 | |
| Оценка: | 3 (1) +1 | |
| Здравствуйте, vladserge, Вы писали: V>Просто делюсь соображениями, возможно что я не одинок.... или это велосипед и я чего то незнаю. Обсудим ? Я перенёс цитаты из твоего диалога с Merle в этом же топике: V>Я подразумеваю только то что подразумевает микрософт описывая Interlocked Class V> V>и далее V>
Вот так бы сразу и сказал. Значит, давай начнём снизу, с процессора. Есть у x86 такой префикс — lock. Префикс lock означает как раз требуемую тебе "атомарность": Цитата отсюда. Дальше... учтём ещё пару интересных факторов. Первый: оговорка в MSDN
Второй: аргументы операций класса Interlocked сводятся к следующим: — int* (адрес 32 битного значения); — Object* (адрес размером 32/64 бита, в зависимости от архитектуры); — int64* (адрес 64-битного целого, только Increment/Decrement и для систем с 64-битным адресом); — Single/float (sizeof() == 4 байта!!!). Притом, инкремента/декремента для float, естественно — нет. Третий: сравним операции системы команд x86 и методы Interlocked: Increment <-> inc Decrement <-> dec Exchange <-> xchg (кстати — всегда атомарна) CompareExchange <-> cmpxchg, cmpxchg8b (для 8-байтовых) Итак. Что получаем? А получаем то, что все методы Interlocked есть ни что иное, как обёртки над командами x86. Притом — каждый над своей. Отсюда становится понятно, почему атомарность обеспечивается только для операций над элементарными целыми типами и не обобщена на уровень произвольного куска кода. Также, становится понятна вышеупомянутая оговорка:
Правильно, поскольку на системах, где арифметические операции с int64 эмулируются программно (а не реализованы аппаратурой), можно только равесить синхронизирующие примитивы в начале и конце Increment/Decrement. А этим можно добиться только того, что выполнение Interlocked.Increment (а равно и Interlocked.Decrement) в потоке A не пересечётся с выполнением такой же операции в потоке B ("these methods are atomic with respect to each other"). Однако, при этом шина обмена с памятью не блокируется процессором в течение всей операции. А значит — возможно переключение управления на планировщик со всеми вытекающими: "not with respect to other means of accessing the data". Т.е., операция м.б. прервана планировщиком, а данные потом модифицированы другим потоком. Понятно также, почему нет аналогичной оговорки для Exchange/CompareExchange: спасают атомарные cmpxchg и cmpxchg8b. <NB> Тут, я полагаю, нужно учесть, что производители процессоров прекрасно осведомлены о том, что хоть для каких-то операций но необходимо уметь обеспечивать атомарность. Для Intel x86 есть префикс lock. Как для других процессоров — не знаю. Скорее всего, такая возможность есть всегда для операций обмена данными, размер которых совпадает с размером адреса. Нужно же как-то синхронизирующие примитивы реализовать для ОС! </NB> Скорее всего, что-то можно наиграть с командами 0-го кольца, но это уже за рамки полномочий .Net выходит. К счастью. V>млин все начинают лезть в такие дебри, вспоминать странные аналогии, а просто прочитать до конца сил ненаходят Это не в порядке наезда, но лучше всего почитай мануал по ассемблеру x86. Там ты найдёшь много интересного, а цитировать всё не хочется. Да, кстати. ИМХО, обеспечивать атомарность выполнения большого куска пользовательского кода для 3-го кольца защиты x86 — чистое самоубийство. А планирощик куда денем? Это — тоже программа. Процессор должен переключиться в её контекст... Прерывания опять таки кто-то обработать должен. ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Re: Ну никаких тут чудес нет и быть не может | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | vladserge | |
| Дата: | 17.10.04 11:03 |
| Здравствуйте, Геннадий Васильев, Вы писали: ГВ>Здравствуйте, vladserge, Вы писали: V>>Просто делюсь соображениями, возможно что я не одинок.... или это велосипед и я чего то незнаю. Обсудим ? ГВ>Я перенёс цитаты из твоего диалога с Merle в этом же топике: V>>Я подразумеваю только то что подразумевает микрософт описывая Interlocked Class V>> V>>и далее V>>
Вот Это ответ!!!
некрасиво, но нужную функциональность, экономичность, а главное высокую скорость имеем, для сервера это критически важно. Еще раз спасибо. С Уважением Сергей Чикирев | |
| Re[2]: Ну никаких тут чудес нет и быть не может | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | VVB16 | |
| Дата: | 17.10.04 12:29 | |
| Оценка: | 1 (1) | |
| Здравствуйте, vladserge, Вы писали: V>Вот Это ответ!!! V>
...Только планировщику ничто не помешает переключить контекст при нахождении внутри if. Ну и вместо locked = 0 тоже надо Interlocked использовать. Фактически это try_lock у мутекса. Сдается мне, что critical section так и реализованы... -- Vitaly Belekhov |
| Re[3]: Ну никаких тут чудес нет и быть не может | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | vladserge | |
| Дата: | 17.10.04 12:42 |
| Здравствуйте, VVB16, Вы писали: VVB>Здравствуйте, vladserge, Вы писали: V>>Вот Это ответ!!! V>>
VVB>...Только планировщику ничто не помешает переключить контекст при нахождении внутри if. фиг с ним, я уже смирился, VVB>... Ну и вместо locked = 0 тоже надо Interlocked использовать. да, в примерах хелпов я обратил на это внимание , но немогу сообразить нафига это сделано так, ведь переменная обнуляется гарантированно только одним потоком который в секции, остальные её только "нюхают" Нет ну правда ЗАЧЕМ? VVB>.. Фактически это try_lock у мутекса. Сдается мне, что critical section так и реализованы... Надо бы проверить на быстродействие, это подтвердит, либо опровергнет (грубо конечно) VVB>-- VVB>Vitaly Belekhov С Уважением Сергей Чикирев | |
| Re[4]: Ну никаких тут чудес нет и быть не может | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | VVB16 | |
| Дата: | 18.10.04 06:35 |
| Здравствуйте, vladserge, Вы писали: V>Здравствуйте, VVB16, Вы писали: VVB>>... Ну и вместо locked = 0 тоже надо Interlocked использовать. V>да, в примерах хелпов я обратил на это внимание , но немогу сообразить нафига это сделано так, ведь переменная обнуляется гарантированно только одним потоком который в секции, остальные её только "нюхают" V>Нет ну правда ЗАЧЕМ? Чтобы она в кэше одного процессора не зависла с одним значением, а в памяти с другим при переключении потоков. Т.е. может возникнуть ситуация, когда locked=0 в одном потоке прошел, а другой через interlocked все еще видит 1. -- Vitaly Belekhov |
| Re[5]: Ну никаких тут чудес нет и быть не может | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | vladserge | |
| Дата: | 18.10.04 09:17 |
| Здравствуйте, VVB16, Вы писали: VVB>Здравствуйте, vladserge, Вы писали: V>>Здравствуйте, VVB16, Вы писали: VVB>>>... Ну и вместо locked = 0 тоже надо Interlocked использовать. V>>да, в примерах хелпов я обратил на это внимание , но немогу сообразить нафига это сделано так, ведь переменная обнуляется гарантированно только одним потоком который в секции, остальные её только "нюхают" V>>Нет ну правда ЗАЧЕМ? VVB>Чтобы она в кэше одного процессора не зависла с одним значением, а в памяти с другим при переключении потоков. VVB>Т.е. может возникнуть ситуация, когда locked=0 в одном потоке прошел, а другой через interlocked все еще видит 1. да, не критически это,а если очень хочется для этого volatile есть С Уважением Сергей Чикирев | |
| Re: Чудеса есть | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 18.10.04 10:15 |
| Здравствуйте, Геннадий Васильев, Вы писали: ГВ>...Есть у x86 такой префикс — lock.... ГВ>...оговорка в MSDN... Ага, смотрим, раз упомянут MSDN значит речь идет о Винде и на 100% о языке Си/Си++; раз упомянут x86 значит идет привязка к конкретной аппаратной платформе. Отсюда, разумеется, следует, что "Ну никаких тут чудес нет и быть не может". А кто бы сомневался, что в Винде на Си/Си++ на x86 чудес нет!!! Чудеса возникают только когда сам язык программирования предоставляет программисту высокоуровневые абстракции для работы с параллельными вычислениями. Натуральный способ добавить возможность параллельных вычислений в объектно ориентированный язык программирования — это ввести такую абстракцию как "активный объект" {ACTIVE}. Для того чтобы натуральным образом синхронизировать работу разных активностей, естественно ввести такую абстракцию как эксклюзивный блок кода {EXCLUSIVE} и явным образом ввести оператор ожидания {AWAIT}. Итого, надо добавить в язык всего три новых ключевых слова {ACTIVE, EXCLUSIVE, AWAIT}. Программу, написанную на таком языке программирования, потом можно портировать на машины с разными архитектурами. Даже на такие, где EXCLUSIVE очень даже будет или, наоборот, совсем не будет поддерживаться на аппаратном уровне, но программу это не касается т.к. это уже проблемы среды исполнения (runtime system). |
| ...осталось свистнуть и принесть! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 19.10.04 01:15 | |
| Оценка: | 6 (1) +2 ![]() | |
| Здравствуйте, Сергей Губанов, Вы писали: ГВ>>...Есть у x86 такой префикс — lock.... ГВ>>...оговорка в MSDN... СГ>Ага, смотрим, раз упомянут MSDN значит речь идет о Винде и на 100% о языке Си/Си++; раз упомянут x86 значит идет привязка к конкретной аппаратной платформе. Отсюда, разумеется, следует, что "Ну никаких тут чудес нет и быть не может". Угу, поскольку не хочется переписывать планировщик, работающий, AFAIK, в 0-м кольце x86. Гораздо проще грамотно спланировать синхронизацию. СГ> А кто бы сомневался, что в Винде на Си/Си++ на x86 чудес нет!!! Это круто! СГ>Чудеса возникают только когда сам язык программирования предоставляет программисту высокоуровневые абстракции для работы с параллельными вычислениями. Натуральный способ добавить возможность параллельных вычислений в объектно ориентированный язык программирования — это ввести такую абстракцию как "активный объект" {ACTIVE}. ИМХО, чудеса возникают там, где не хватает знаний и понимания реальности. Э... для наблюдателей, естественно. Для чудотворцев-то чудес никаких нет. СГ>Для того чтобы натуральным образом синхронизировать работу разных активностей, естественно ввести такую абстракцию как эксклюзивный блок кода {EXCLUSIVE} и явным образом ввести оператор ожидания {AWAIT}. ИМХО, ты заблуждаешься. Ничего тут естественного нет — в смысле, что язык необязательно модифицировать. Сам по себе EXLUSIVE — критическая секция и всё. Особенность — в планировщике задач Aos, который несколько необычно (не)переключает контексты — не только по таймеру, но и по другим событиям. И работает такой прикол (исключительное выполнение) только на однопроцессорных машинах, поскольку второй процессор в EXCLUSIVE-время тоже девать куда-то надо. Об этом и сами создатели пишут в техническом описании Aos. А если процессоров больше одного — то получаем банальную критическую секцию "в профиль". Что касается AWAIT — то есть и conditional vars. А в винде есть Events. ИМХО — более чем смахивает на AWAIT. Здесь преимущество Aos в относительной элегантности языковой конструкции, ну и всё. И больше ничего, вобщем-то. СГ> Итого, надо добавить в язык всего три новых ключевых слова {ACTIVE, EXCLUSIVE, AWAIT}. Программу, написанную на таком языке программирования, потом можно портировать на машины с разными архитектурами. Даже на такие, где EXCLUSIVE очень даже будет или, наоборот, совсем не будет поддерживаться на аппаратном уровне, но программу это не касается т.к. это уже проблемы среды исполнения (runtime system). Ну, это зависит от... ИМХО, для C++ более чем достаточно библиотечных примитивов. Условно, синтаксис может быть таким:
А дальше можно довернуть всё, что хочешь. ИМХО — на порядок гибче, чем введение в язык нового ключевого слова. Кстати, насколько я пока что понял — в Aos чекируются чуть ли не все вызова, а это скорости, ИМХО, добавлять не должно. Что, кстати, косвенно подтверждается их же тестами (посмотри в разделе 8.2, там есть не только сравнение длительности системного вызова). Не, ты не подумай. Я против Aos ровным счётом ничего не имею — неплохая вполне разработка. Очень интересная, кстати. Но и делать из неё абсолютный пример для подражания, ИМХО — не верно. Одно только общее адресное пространство и единственный язык чего стоят! Та разница в длительности системных вызовов, о которой ты так часто вспоминаешь, на самом деле всего лишь следствие того, что Aos вертится в одном кольце защиты, а Linux — в четырёх. Т.е., немалая доля задержек обуславливается переключением колец защиты (а не только контекстов процессов). Если тебе хватит для синхронизации локальных блокировок (см. префикс LOCK), то можно выдавить максимальное быстродействие. ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Re[4]: Ну никаких тут чудес нет и быть не может | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 19.10.04 02:05 |
| Здравствуйте, vladserge, Вы писали: VVB>>... Ну и вместо locked = 0 тоже надо Interlocked использовать. V>да, в примерах хелпов я обратил на это внимание , но немогу сообразить нафига это сделано так, ведь переменная обнуляется гарантированно только одним потоком который в секции, остальные её только "нюхают" V>Нет ну правда ЗАЧЕМ? Некоторые машины могут футболить данные в память из кэша не в порядке обновления, а в порядке возрастания адресов (relaxed memory model). Для того, чтобы этого не случилось, используют барьеры памяти (memory barriers), которые гарантируют, что данные, модифицированные ранее инструкции барьера 100% попадут в основную память. А иначе ты можешь на многопроцессорной архитектуре получить, что значение locked=0 попадёт второму процессору раньше, чем результаты отработки того, что было между инструкциями:
и
Т.е., на однопроцессорной машине не страшно, можно и так, как ты написал. На многопроцессорной может быть весьма опасным. Зависит от архитектуры. Кстати, вот цитата из MSDN-описания C-шной функции InterlockedIncrement:
Вот тебе и ответ: вероятнее всего, методы Interlocked тоже тянут барьеры. PS. Об этом явлении совсем немного есть у Александреску. ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Re[6]: Ну никаких тут чудес нет и быть не может | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | VVB16 | |
| Дата: | 19.10.04 05:58 | |
| Оценка: | 1 (1) | |
| Здравствуйте, vladserge, Вы писали: VVB>>Чтобы она в кэше одного процессора не зависла с одним значением, а в памяти с другим при переключении потоков. VVB>>Т.е. может возникнуть ситуация, когда locked=0 в одном потоке прошел, а другой через interlocked все еще видит 1. V>да, не критически это,а если очень хочется для этого volatile есть Кратко: volatile не поможет, это для компилятора совет, а для процессора он ничего не значит. Можешь поиском найти статьи про double-checked locking и про то, что он практически не реализуем без специальной поддержки со стороны процессора (о чем хорошо знаю Java-developers, походившие с ним по граблям). Тут та же самая причина. -- Vitaly Belekhov |
| Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 19.10.04 18:22 |
| Здравствуйте, GlebZ, Вы писали: GZ>Товарищ, вы отстаете от моды. Сейчас модно защищать объекты, а не просто куски кода. Наглядный пример из NET: GZ>
GZ>В результате, есть ГАРАНТИЯ правильной синхронизации объекта как внутри, так и снаружи. Защищаются именно данные а не действия над ним (и ессно в разумной степени). И никакой гарантии защиты от дедлоков. Почему? Потому что объект блокирует сам себя ( lock(this) ), а на самом деле блокировка должна выполняться извне объекта, в зависимости от способа его обработки. GZ>Защита какой-то отдельной процедуры практически никогда не нужно, и самое главное вредно. У тебя нет никакой гарантии, что при дальнейшем развитии не будет написана другая процедура работающая с этими данными. То же самое справедливо и для самозащиты объекта. ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Re[8]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 19.10.04 18:27 |
| Здравствуйте, Merle, Вы писали: M>Допустим есть ресурс, который захватывается и освобождается много раз в течении кванта потока. M>Если переключение контекста произошло в тот момент, когда ресурс захвачен, другие потоки, бесполезно покрутившись на спинлоке, впадают в спячку, поставив себя в очередь. Если же переключение контекста произошло в тот момент, когда ресурс свободен, то ресурс оказывается немедленно захвачен другим потоком, а первоначальный поток, при попытке опять воспользоваться ресурсом, попадает на ожидание и оказывается в конце очереди. Со временем очередь только растет и конвой не рассасывается до возникновения какой-нибудь нерегулярности. И дальше по кругу — ни один поток не может удержать ресурс дольше небольшой доли кванта (квант / сколько раз за квант ресурс захватывается потоком). Угу. ИМХО, как раз поэтому лучше всего блокировать все необходимые ресурсы до начала операции с ними. Заодно и разруливание ошибок захвата упрощается. ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Re: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sinclair rsdn | http://www.parallels.com/automation/operations/ |
| Дата: | 20.10.04 03:20 | |
| Оценка: | +1 | |
| Re: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | GlebZ | |
| Дата: | 20.10.04 07:21 |
| Здравствуйте, Геннадий Васильев, Вы писали: ГВ>И никакой гарантии защиты от дедлоков. Почему? Потому что объект блокирует сам себя ( lock(this) ), а на самом деле блокировка должна выполняться извне объекта, в зависимости от способа его обработки. Объект синхронизации защищает только от чужих потоков. Для своего потока он только подсчитывает число входов и выходов. Таким образом, deadlock для одного потока не будет. Для остальных потоков, блокировка действительна и следует следить за атомарностью изменений в контексте первого в стеке lock. Собственно, это и есть основное предназначение синхронизации. С уважением, Gleb. |
| Re[2]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 20.10.04 15:33 |
| Здравствуйте, Sinclair, Вы писали: S>Здравствуйте, Геннадий Васильев, Вы писали: ГВ>>И никакой гарантии защиты от дедлоков. Почему? Потому что объект блокирует сам себя ( lock(this) ), а на самом деле блокировка должна выполняться извне объекта, в зависимости от способа его обработки. S>Что-то я не понимаю, каким образом самоблокировка вызовет дедлоки. Особенно в противовес внешней блокировке. Нет никакой связи между глубиной вызова lock в стеке и вероятностью deadlock.
Такую ситуацию попросту сложно ловить: вроде бы, все объекты "правильно" блокируют сами себя, но в сумме получается дедлок при перекрёстной связи. Почему? Потому что может сложиться ситуация, когда my_a будет заблокирован из A.m1(), а my_b — из B.m2(). При этом они не смогут продолжить вычисления: первый запнётся на вызове b.m1(), а второй — на a.m2(). А если это ещё и на большой глубине стека происходит, да при неявных зависимостях классов, то секс почти гарантирован. ИМХО, правильное решение должно быть таким:
Обязательное условие: порядок захвата объектов должен быть одинаковым в обоих случаях!!! ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Re[2]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 20.10.04 15:33 |
| Здравствуйте, GlebZ, Вы писали: GZ>Объект синхронизации защищает только от чужих потоков. Для своего потока он только подсчитывает число входов и выходов. Таким образом, deadlock для одного потока не будет. Для остальных потоков, блокировка действительна и следует следить за атомарностью изменений в контексте первого в стеке lock. Собственно, это и есть основное предназначение синхронизации. Проблема в том, что таких объектов может оказаться не один, и тут-то всё и начнётся. См. соседний пост. ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Re[3]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sinclair rsdn | http://www.parallels.com/automation/operations/ |
| Дата: | 21.10.04 04:35 |
| Re[3]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | GlebZ | |
| Дата: | 21.10.04 07:28 |
| Здравствуйте, Геннадий Васильев, Вы писали: ГВ>
Замечательная конструкция. Сразу хочется сказать несколько вещей: 1. Явная ошибка программиста введена сознательно? Если другой объект является расшаренным между несколькими объектами, то при выполнении нужно его синхронизировать. Согласись, это азы. 2. Отсутсвие deadlock никто никогда не гарантировал. Если есть 2 mutex, взаимная блокировка возможна, независимо от того как ты блокируешь (см. пример Sinclair). Вопрос, можно ли это контролировать. 3. Неконтролируемый вход DeadLock в данной ситуации невозможен. Оба объекта должны быть видны друг другу, и соответсвенно делались в одном и том же приложении. Соответсвенно, это контролируемая ситуация, и ты вряд ли сможешь попасть в deadlock с объектом, реализация которого тебе неизвестна. 4. При правильном теоретическом подходе, любую идею можно испортить. С уважением, Gleb. |
| Re[3]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 21.10.04 07:40 | |
| Оценка: | 10 (2) | |
| Здравствуйте, Геннадий Васильев, Вы писали: GZ>>Объект синхронизации защищает только от чужих потоков. Для своего потока он только подсчитывает число входов и выходов. Таким образом, deadlock для одного потока не будет. Для остальных потоков, блокировка действительна и следует следить за атомарностью изменений в контексте первого в стеке lock. Собственно, это и есть основное предназначение синхронизации. ГВ>Проблема в том, что таких объектов может оказаться не один, и тут-то всё и начнётся. См. соседний пост. Дедлок можно получить разными способами, не обязательно на мониторах. Любое синхронизированное действие — например, чтение/запись файла, внешнего устройства — чревато взаимоблокировкой. Впрочем, есть способы борьбы с таким явлением: 1) Конечные таймауты. Ждать не до посинения, а некоторое разумное время, после чего обламываться (и повторять попытку) 2) Построить граф блокировок. Он должен быть ациклическим. Это делается на стадии проектирования! Но и во время исполнения можно построить текущий граф и проверить его на циклы; если очередная блокировка создаёт цикл — это исключительная ситуация. 3) Есть 3 кондовых способа реализации ациклических графов: 3.1) Единственный синхрообъект 3.2) Потоку разрешается захват единственного синхрообъекта в каждый момент времени 3.3) Все синхрообъекты пронумерованы, и захватывать надо не только один, но и все предшествующие Перекуём баги на фичи! |
| Re[4]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Merle rsdn | http://rsdn.ru |
| Дата: | 21.10.04 08:16 | |
| Оценка: | 2 (1) | |
| Здравствуйте, Кодт, Вы писали: К>2) Построить граф блокировок. Он должен быть ациклическим. Угу, он же Wait-for Graph — граф ожидания. Но тут встает вопрос, как часто проводить проверку на ацикличность графа? Слишком часто — будет накладно, слишком редко, долго разруливать конфликт... Зато при этом способе можно откатить не кого попало, а в соответствии с логикой приложения. Есть еще один способ, на основе time-stamp'ов...
... [ RSDN@Home 1.1.4 revision 142 ] Мы уже победили, просто это еще не так заметно... |
| Re[5]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | GlebZ | |
| Дата: | 21.10.04 08:26 |
| Здравствуйте, Merle, Вы писали: Замечательная вещь, откаты в рантайме, на компиленном коде. Будем создавать паттерн Command везде где только можно? С уважением, Gleb |
| Re[6]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sinclair rsdn | http://www.parallels.com/automation/operations/ |
| Дата: | 21.10.04 08:37 |
| Здравствуйте, GlebZ, Вы писали: GZ>Замечательная вещь, откаты в рантайме, на компиленном коде. Будем создавать паттерн Command везде где только можно? А есть какие-то альтернативы? Не нравятся откаты — вообще избегайте блокировок. Пользуйтесь Гармонично Взаимодействующими Процессами (с) Дийкстра. Благо в винде, например, все для них уже сделано Вообще, конечно, можно и без откатов. При детектировании дедлока можно просто выкидывать исключение из функции lock. Это по крайней мере лучше, чем просто ждать ресета. ... << RSDN@Home 1.1.4 beta 3 rev. 185>> Уйдемте отсюда, Румата! У вас слишком богатые погреба. | |
| Re[6]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Merle rsdn | http://rsdn.ru |
| Дата: | 21.10.04 08:37 |
| Здравствуйте, GlebZ, Вы писали: GZ>Замечательная вещь, откаты в рантайме, на компиленном коде. Будем создавать паттерн Command везде где только можно? Это уже другой вопрос. Я в данном случае рассматриваю "сферического коня в вакуме", некоторая абстрактная задача по разруливанию дедлоков. Я в полне допускаю, что в реальных приложениях любая из предложеных стратегий может оказаться наиболее оптимальной. Не согласны? ... [ RSDN@Home 1.1.4 revision 142 ] Мы уже победили, просто это еще не так заметно... |
| Re[4]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | GlebZ | |
| Дата: | 21.10.04 08:42 |
| Здравствуйте, Кодт, Вы писали: Все прекрасно, если бы не практика. К>Впрочем, есть способы борьбы с таким явлением: К>1) Конечные таймауты. Ждать не до посинения, а некоторое разумное время, после чего обламываться (и повторять попытку) Хорошая и правильная идея. Еще бы спецификация lock позволяла бы устанавливать TimeOut, после которого генерился бы Exception, было бы круто. К>2) Построить граф блокировок. Он должен быть ациклическим. Это делается на стадии проектирования! Согласен, абсолютно и полностью. К>Но и во время исполнения можно построить текущий граф и проверить его на циклы; если очередная блокировка создаёт цикл — это исключительная ситуация. Напишем RSDN SQL, и все в порядке. Сколько это решение стоить будет. К>3) Есть 3 кондовых способа реализации ациклических графов: К>3.1) Единственный синхрообъект Недостаток вполне понятный, производительность. И иногда это невозможно. К>3.2) Потоку разрешается захват единственного синхрообъекта в каждый момент времени Недостаток, невозможно сделать атомарность изменений. К>3.3) Все синхрообъекты пронумерованы, и захватывать надо не только один, но и все предшествующие Недостаток в производительности. Но при определенных ситуациях и решениях, вполне сносный способ. Из данного сообщения, я бы все таки выделил ваше предложение: Построить граф блокировок. Он должен быть ациклическим. Это делается на стадии проектирования. С уваженим, Gleb. |
| Re[7]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | GlebZ | |
| Дата: | 21.10.04 08:49 |
| Здравствуйте, Sinclair, Вы писали: S>Здравствуйте, GlebZ, Вы писали: GZ>>Замечательная вещь, откаты в рантайме, на компиленном коде. Будем создавать паттерн Command везде где только можно? S>А есть какие-то альтернативы? Не нравятся откаты — вообще избегайте блокировок. Пользуйтесь Гармонично Взаимодействующими Процессами (с) Дийкстра. Благо в винде, например, все для них уже сделано S>Вообще, конечно, можно и без откатов. При детектировании дедлока можно просто выкидывать исключение из функции lock. Это по крайней мере лучше, чем просто ждать ресета. Второе утверждение мне больше нравится. В соседнем посте написал, к сожалению еще до того как получил до вашего сообщения. С уважением, Gleb |
| Re[7]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | GlebZ | |
| Дата: | 21.10.04 08:59 |
| Здравствуйте, Merle, Вы писали: M>Здравствуйте, GlebZ, Вы писали: GZ>>Замечательная вещь, откаты в рантайме, на компиленном коде. Будем создавать паттерн Command везде где только можно? M>Это уже другой вопрос. Я в данном случае рассматриваю "сферического коня в вакуме", некоторая абстрактная задача по разруливанию дедлоков. M>Я в полне допускаю, что в реальных приложениях любая из предложеных стратегий может оказаться наиболее оптимальной. M>Не согласны? Хотя в принципе, почему бы и нет? Нет решений которые невозможно применить, просто задачи где такое решение оптимально не часто на практике попадаются. Теоретически, даже на уровне компилированного кода, могу придумать много задач где данное решение будет эффективным. С уважением, Gleb. |
| Re[5]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 21.10.04 09:21 |
| Здравствуйте, Merle, Вы писали: M>Здравствуйте, Кодт, Вы писали: К>>2) Построить граф блокировок. Он должен быть ациклическим. M>Угу, он же Wait-for Graph — граф ожидания. M>Но тут встает вопрос, как часто проводить проверку на ацикличность графа? Слишком часто — будет накладно, слишком редко, долго разруливать конфликт... Зато при этом способе можно откатить не кого попало, а в соответствии с логикой приложения. Проверять нужно всегда (то есть, каждая операция захвата вносит коррективы в граф ожидания), но не для всех объектов. Все синхрообъекты делятся на 2 категории: мгновенные и тормозные. Мгновенные — это мониторы доступа к разделяемым данным. Залез, ковырнул, вылез. На стадии проектирования (или отладки) избегаем взаимных блокировок, да и вообще длительного пребывания внутри. А с тормозными — можно и проверять. M>Есть еще один способ, на основе time-stamp'ов... Для взаимодействия клиент-сервер вариант отлуп-повтор транзакции это обычное дело. А вот внутри программы, пожалуй, любой отлуп — это исключительная ситуация. Плюс накладные расходы на откат транзакции. Перекуём баги на фичи! |
| Re[6]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Merle rsdn | http://rsdn.ru |
| Дата: | 21.10.04 09:35 |
| Здравствуйте, Кодт, Вы писали: К>Проверять нужно всегда (то есть, каждая операция захвата вносит коррективы в граф ожидания), но не для всех объектов. При достаточно большом графе это может быть очень дорогой операцией. AFAIK ни одна СУБД (это как раз тот класс приложений где оптимальная проверка на взаимоблокировки одна из критичных частей), с deadlock монитором на основе графа ожидания не проверяет граф при каждом изменении, только по таймауту. К>Все синхрообъекты делятся на 2 категории: мгновенные и тормозные. К>Мгновенные — это мониторы доступа к разделяемым данным. Залез, ковырнул, вылез. На стадии проектирования (или отладки) избегаем взаимных блокировок, да и вообще длительного пребывания внутри. К>А с тормозными — можно и проверять. Можно комбинировать несколько подходов, собственно в тех же СУБД так и поступают. Для "легких" объектов используют правило "не больше одной блокировки", а для "тяжелых" строится граф. К>А вот внутри программы, пожалуй, любой отлуп — это исключительная ситуация. Плюс накладные расходы на откат транзакции. Угу, но ситуации могут быть разными... Есть еще решения для частных случаев, например, если граф объектов нуждающихся в синхронизации сам по себе представляет DAG, то есть алгоритмы гарантирующие отсутствие дедлоков. ... [ RSDN@Home 1.1.4 revision 142 ] Мы уже победили, просто это еще не так заметно... |
| Re[5]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 21.10.04 11:15 |
| Здравствуйте, GlebZ, Вы писали: К>>Но и во время исполнения можно построить текущий граф и проверить его на циклы; если очередная блокировка создаёт цикл — это исключительная ситуация. GZ>Напишем RSDN SQL, и все в порядке. Сколько это решение стоить будет. Я сталкивался с проблемой дедлоков в многопоточном приложении с запутанной архитектурой. Поскольку грамотно переосмыслить и перепроектировать тогда не удалось, сделал несложный механизм отслеживания циклов в реальном времени. Строятся 2 таблицы — захвата ресурсов и ожидания потоков. Перед захватом мутекса выполняется проверка и модификация этих таблиц; после освобождения — снова модификация. Для отладочных целей — вполне хватало, даже производительность не сильно падала. Перекуём баги на фичи! |
| Re[6]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | GlebZ | |
| Дата: | 21.10.04 12:18 |
| Здравствуйте, Кодт, Вы писали: К>Я сталкивался с проблемой дедлоков в многопоточном приложении с запутанной архитектурой. Поскольку грамотно переосмыслить и перепроектировать тогда не удалось, сделал несложный механизм отслеживания циклов в реальном времени. К>Строятся 2 таблицы — захвата ресурсов и ожидания потоков. Перед захватом мутекса выполняется проверка и модификация этих таблиц; после освобождения — снова модификация. К>Для отладочных целей — вполне хватало, даже производительность не сильно падала. Спасибо за учение, приму к сведению что данный вариант реализуем. Если не секрет, чем циклы находили? С уважением, Gleb. |
| Re[7]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 21.10.04 14:10 | |
| Оценка: | 21 (1) | |
| Здравствуйте, GlebZ, Вы писали: GZ>Спасибо за учение, приму к сведению что данный вариант реализуем. Если не секрет, чем циклы находили? Руками, чем же ещё
Перекуём баги на фичи! |
| Re[4]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 21.10.04 16:53 |
| Здравствуйте, Кодт, Вы писали: GZ>>>Объект синхронизации защищает только от чужих потоков. Для своего потока он только подсчитывает число входов и выходов. Таким образом, deadlock для одного потока не будет. Для остальных потоков, блокировка действительна и следует следить за атомарностью изменений в контексте первого в стеке lock. Собственно, это и есть основное предназначение синхронизации. ГВ>>Проблема в том, что таких объектов может оказаться не один, и тут-то всё и начнётся. См. соседний пост. К>Дедлок можно получить разными способами, не обязательно на мониторах. К>Любое синхронизированное действие — например, чтение/запись файла, внешнего устройства — чревато взаимоблокировкой. Э, погоди. К>Впрочем, есть способы борьбы с таким явлением: И естественно, что с любым явлением есть свои способы борьбы — иначе програмирование навсегда бы остановилось. На мой взгляд, опасно излишне увлекаться самоблокировкой объектов, хотя в некоторых случаях это — вполне адекватное решение. Например — для синглтонов, которые управляют распределением памяти. Почему нет? Проблемы могут быть если: а) увлечься самоблокируемыми объектами и б) завязать их в кучу. ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Re[4]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 21.10.04 16:53 |
| Здравствуйте, Sinclair, Вы писали: S>Именно поэтому я и говорю, что вероятность дедлока никак не связана с расположением блокирующего кода. Преимущество в том, что если ты словил дедлок в самоблокирующемся коде, то его можно за нефиг делать разрулить. Этого можно было и не писать. ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Re[4]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 21.10.04 16:55 |
| Здравствуйте, GlebZ, Вы писали: GGZ>Замечательная конструкция. Сразу хочется сказать несколько вещей: GZ>1. Явная ошибка программиста введена сознательно? Если другой объект является расшаренным между несколькими объектами, то при выполнении нужно его синхронизировать. Согласись, это азы. Соглашусь. Но это может быть труднопонимаемыми азами, если увлечься модой. GZ>2. Отсутсвие deadlock никто никогда не гарантировал. Если есть 2 mutex, взаимная блокировка возможна, независимо от того как ты блокируешь (см. пример Sinclair). Вопрос, можно ли это контролировать. Зависит от дизайна и трезвомыслия дизайнера. Потому я и не люблю выражение "модно" по отношению к реализации технических устройств. GZ>3. Неконтролируемый вход DeadLock в данной ситуации невозможен. Оба объекта должны быть видны друг другу, и соответсвенно делались в одном и том же приложении. С этим можно поспорить, поскольку например A может быть на самом деле унаследован от какого-то несамоблокируемого Z, который реализован вместе с B. Впрочем — так фантазировать можно долго. GZ> Соответсвенно, это контролируемая ситуация, и ты вряд ли сможешь попасть в deadlock с объектом, реализация которого тебе неизвестна. Ну... если мне неизвестна реализация объекта, то мне ничего неизвестно о нём кроме соглашений об интерфейсах. GZ>4. При правильном теоретическом подходе, любую идею можно испортить. Э... Ура! ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Re[5]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | GlebZ | |
| Дата: | 22.10.04 09:23 |
| Здравствуйте, Геннадий Васильев, Вы писали: ГВ>Здравствуйте, GlebZ, Вы писали: ГВ>Зависит от дизайна и трезвомыслия дизайнера. Потому я и не люблю выражение "модно" по отношению к реализации технических устройств. см снизу ГВ>Ну... если мне неизвестна реализация объекта, то мне ничего неизвестно о нём кроме соглашений об интерфейсах. Почему я написал именно "модно". Дело в том, что у меня нет информации из доверяемых мною источников, что не произойдет некотнролируемый deadlock (или не произойдет). Что подразумевается под термином неконтролируемый deadlock: неконтролируемый deadlock — deadlock который нельзя выявить организационными или другими (как показал Koдт) мерами. То есть, если ты обладаешь только интерфейсом (имеется в виду интерфейс класса) некоторого instance написанного внешним разработчиком, можешь ли ты его блокировать не попадая в ситуацию deadlock. Поскольку у меня нет сведений в обратном, я использую данный метод, благо он действительно удобен в вышеописанной ситуации. Именно поэтому, я скептически указал именно "модно". Должен, правда, покаятся, что данные источники не искал (как то всегда существуют более насущные проблемы). Вышеописанные вами ситуации, с помощью организационных мер, вполне разрешимы. С уважением, Gleb. |
| Re[6]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 22.10.04 14:01 |
| Здравствуйте, GlebZ, Вы писали: ГВ>>Ну... если мне неизвестна реализация объекта, то мне ничего неизвестно о нём кроме соглашений об интерфейсах. GZ>Почему я написал именно "модно". Дело в том, что у меня нет информации из доверяемых мною источников, что не произойдет некотнролируемый deadlock (или не произойдет). Что подразумевается под термином неконтролируемый deadlock: неконтролируемый deadlock — deadlock который нельзя выявить организационными или другими (как показал Koдт) мерами. То есть, если ты обладаешь только интерфейсом (имеется в виду интерфейс класса) некоторого instance написанного внешним разработчиком, можешь ли ты его блокировать не попадая в ситуацию deadlock. GZ>Поскольку у меня нет сведений в обратном, я использую данный метод, благо он действительно удобен в вышеописанной ситуации. Именно поэтому, я скептически указал именно "модно". Должен, правда, покаятся, что данные источники не искал (как то всегда существуют более насущные проблемы). Вышеописанные вами ситуации, с помощью организационных мер, вполне разрешимы. Хмм... ну, я не совсем понял, о чём здесь идёт речь. Извини пожалуйста, или переформулируй. ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Re: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | 0xDEADBEEF | |
| Дата: | 09.11.04 15:29 | |
| Оценка: | +1 | |
| Здравствуйте, vladserge, Вы писали: V>Привет всем! V>Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него). ...то есть, заставить планировщика не переключать потоки до тех пор пока, блок не выполнится? Типа старого доброго CLI/STI под Досом? Не получится. И смотри почему. — это полностью разрушит preemptive multitasking. Предположим ты засунул с "atom"-блок всю свою программу. — что делать планировщику на многопроцессорных машинах? Морозить все потоки что выполняются на других процессорах пока твой любимый атомарный блок не соизволит кончиться? __________ | 16.There is no cause so right that one cannot find a fool following it. |
| Re[2]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 10.11.04 09:03 | |
| Оценка: | -1 | |
| Здравствуйте, 0xDEADBEEF, Вы писали: DEA> Не получится. Получится. Уже реализовано: http://www.rsdn.ru/Forum/Message.aspx?mid=851366&only=1 Автор: Сергей Губанов Дата: 14.10.04 |
| Re[3]: Атомарность | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sinclair rsdn | http://www.parallels.com/automation/operations/ |
| Дата: | 10.11.04 09:36 | |
| Оценка: | +2 | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Получится. Уже реализовано: http://www.rsdn.ru/Forum/Message.aspx?mid=851366&only=1 Автор: Сергей Губанов Дата: 14.10.04 Не надо ля-ля уже. Перечитай исходный постинг, и сравни со своим. Либо ты не понимаешь, чем отличается "недопуская переключения потока" от "до того как кто-то другой захочет выполнить это же самое действие", то тебе категорически противопоказано заниматься программированием. ... << RSDN@Home 1.1.4 beta 3 rev. 185>> Уйдемте отсюда, Румата! У вас слишком богатые погреба. | |
| Re[7]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | stalcer | |
| Дата: | 01.04.05 12:20 |
| Здравствуйте, Sinclair, Вы писали: S>Пользуйтесь Гармонично Взаимодействующими Процессами (с) Дийкстра. Че-то не гуглится |
| Re[8]: Дедлоки! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | GlebZ | |
| Дата: | 01.04.05 17:15 |
| Здравствуйте, stalcer, Вы писали: S>Здравствуйте, Sinclair, Вы писали: S>>Пользуйтесь Гармонично Взаимодействующими Процессами (с) Дийкстра. S>Че-то не гуглится Dijkstra, "Cooperating sequential processes" С уважением, Gleb. ... << RSDN@Home 1.1.4 beta 4 rev. 358>> |