| 1 2 3 4 5 |
| Атомарность | |
| От: | vladserge | ||
| Дата: | 14.10.04 05:47 | ||
| Оценка: | 2 (1) | ||
| Привет всем! Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него). например так
во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации. В .NET кое что на эту тему появилось, я про Interlocked, но вырозительности и прозрачности использования нет зацените сами
понятно, что найдуться чайники которые начнут внутрь атомарного кода пихать длительные операции приводя к завесалову всей системы. Но с этим можно бороться, например подразумевая что НЕпереключения потоков внутри атомарного кода происходит только в контексте приложения, а не всей системы. Таким образом если некто напишет ахинею типа
то зависнет только это приложение. Просто делюсь соображениями, возможно что я не одинок.... или это велосипед и я чего то незнаю. Обсудим ? С Уважением Сергей Чикирев |
| Re: Атомарность | |
| От: | Сергей Губанов | ||
| Дата: | 14.10.04 06: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 | ||
| Дата: | 14.10.04 07:22 | ||
| Оценка: | +1 | ||
| Здравствуйте, vladserge, Вы писали: V>Привет всем! V>Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него). Видите ли, переключение потока — это системная операция, и хорошо бы, чтобы язык высокого уровня не имел к ней доступа. Это все равно что требовать, чтобы вот на этом участке кода процессор не переключался на другой процесс. Я полагаю, Вы хотите достигнуть атомарности операции. Переключение потоков здесь ни при чем. Просто надо обеспечить условия для того, чтобы другой поток не "увидел" результаты вашей операции, пока она до конца не выполнилась. В Java для этого используются мониторы и ключевое слово synchronized. Переписывая Ваш пример:
При заходе в блок synchronized монитор, ассоциированный с объектом lock, включается, и другие потоки не смогут войти в блок с таким же монитором, пока тот не освободится. По моему, очень удобная и высокоуровневая конструкция, учитывая дополнительные возможности Java с ключевым словом synchronized. |
| Re: Атомарность | |
| От: | WolfHound rsdn | ||
| Дата: | 14.10.04 08:02 | ||
| Оценка: | +1 | ||
| Здравствуйте, vladserge, Вы писали: V>В .NET кое что на эту тему появилось, я про Interlocked, но вырозительности и прозрачности использования нет V>зацените сами Ну это появилось не в .НЕТ, а гораздо раньше
V>понятно, что найдуться чайники которые начнут внутрь атомарного кода пихать длительные операции приводя к завесалову всей системы. Но с этим можно бороться, например подразумевая что НЕпереключения потоков внутри атомарного кода происходит только в контексте приложения, а не всей системы. Таким образом если некто напишет ахинею типа Гм. ИМХО мысль не плохая. Но ИМХО придется вводить поддержку на уровне операционной системы. Тут есть форум в котором можно задать вопросы ребятам из Майкрософт... спроси у них. ... << RSDN@Home 1.1.4 rev. 185 >> Пусть это будет просто: просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[2]: Атомарность | |
| От: | WolfHound rsdn | ||
| Дата: | 14.10.04 08:02 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>EXCLUSIVE — как раз и гарантирует, что указанное действие должно выполниться полностью, до того как кто-то другой захочет выполнить это же самое действие, вот Вам и "атомарность": СГ>
Если да то что мешает другому потоку обратиться к рассогласованым x, y? ... << RSDN@Home 1.1.4 rev. 185 >> Пусть это будет просто: просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[2]: Атомарность | |
| От: | vladserge | ||
| Дата: | 14.10.04 08:16 |
| Здравствуйте, sereda, Вы писали: S>Здравствуйте, vladserge, Вы писали: V>>Привет всем! V>>Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него). S>Видите ли, переключение потока — это системная операция, и хорошо бы, чтобы язык высокого уровня не имел к ней доступа. Это все равно что требовать, чтобы вот на этом участке кода процессор не переключался на другой процесс. именно этого и хочется, я ж ясно выразился, как впрочем и для чего. S>Я полагаю, Вы хотите достигнуть атомарности операции. Переключение потоков здесь ни при чем. Просто надо обеспечить условия для того, чтобы другой поток не "увидел" результаты вашей операции, пока она до конца не выполнилась. дивно, а не проще ли систнмному диспетчеру процессов обнаружить что он внутри атомарного блока и не деактивировать текущий процесс и переключаться на доругой. Это ОЧЕНЬ ДОРОГО !!!!!! S>В Java для этого используются мониторы и ключевое слово synchronized. нужно будет записать, а то забуду S>По моему, очень удобная и высокоуровневая конструкция, учитывая дополнительные возможности Java с ключевым словом synchronized. Спасибо за ответ, но на будущее просьба, до конца читать пост на который Вы отвечаете. Я ж ведь не графоман какой, то и когда пишу буквально во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации. то это я делаю специально для Вас. С Уважением Сергей Чикирев |
| Re[2]: Атомарность | |
| От: | vladserge | ||
| Дата: | 14.10.04 08:22 |
| Здравствуйте, WolfHound, Вы писали: WH>Здравствуйте, vladserge, Вы писали: V>>В .NET кое что на эту тему появилось, я про Interlocked, но вырозительности и прозрачности использования нет V>>зацените сами WH>Ну это появилось не в .НЕТ, а гораздо раньше Ошибся хотел написать В например .NET кое что на эту тему есть далее по тексту.... V>>Гм. ИМХО мысль не плохая. Но ИМХО придется вводить поддержку на уровне операционной системы. Ну я тут не о трудностях, а об удобстве и необходимости фичи рассуждаю. V>>Тут есть форум в котором можно задать вопросы ребятам из Майкрософт... спроси у них. Пока ясовсем неуверен, что это кому нибудь, кроме меня может быть интересно. а там .... будем посмотреть. PS спасибо за ответ С Уважением Сергей Чикирев |
| Re: Атомарность | |
| От: | Кодт rsdn | ||
| Дата: | 14.10.04 08:30 | ||
| Оценка: | 15 (4) | ||
| Здравствуйте, vladserge, Вы писали: V>во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации. ... но, в отличие от мониторов/крит.секций, не гарантирует целостности. Пример:
Запустили оба потока. Первый: взял x... (и был вытеснен) Второй: обменял x,y Первый: взял y и напечатал. Что мы видим? Правильно: 1,1 Поскольку мониторы очень и очень распространены, специально для этого любая нормальная ОС содержит легковесные средства их реализации. Например, под виндоузом есть два мутекса — "дорогой" HMUTEX и "дешёвый" CRITICAL_SECTION. Первый — это объект ядра, все операции над ним требуют проваливания в нулевое кольцо. Второй — объект пользователя, сделанный чуть ли не на InterlockedExchange() / Sleep(). Перекуём баги на фичи! |
| Re[3]: Атомарность | |
| От: | sereda | ||
| Дата: | 14.10.04 08:36 |
| Здравствуйте, vladserge, Вы писали: V>Спасибо за ответ, но на будущее просьба, до конца читать пост на который Вы отвечаете. Я ж ведь не графоман какой, то и когда пишу буквально V>во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации. V>то это я делаю специально для Вас. Спасибо Вам за то, что Вы делаете специально для меня. Я прочитал Ваш пост еще раз внимательно. Конечно, очевидно, что в цитируемой Вами фразе Вы имели в виду и synchronized в Java. Покорнейше прошу прощения за то, что не заметил сразу, и что купился на предложение обсудить вопрос. По теме. Если вы хотите сэкономить на context switching'e, то надо от языков требовать поддержки атомарных команд процессора вроде TestAndSet. Блокировать context switching грубой силой — это значит рисковать из-за ошибок нарушить работу не только приложения, но и всей операционки. Не думаю, что этот риск оправдан соображениями производительности. |
| Re[2]: Атомарность | |
| От: | vladserge | ||
| Дата: | 14.10.04 08:49 |
| Здравствуйте, Кодт, Вы писали: К>Здравствуйте, vladserge, Вы писали: V>>во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации. К>... но, в отличие от мониторов/крит.секций, не гарантирует целостности. К>Пример: К>
К>Запустили оба потока. К>Первый: взял x... (и был вытеснен) К>Второй: обменял x,y К>Первый: взял y и напечатал. К>Что мы видим? Правильно: 1,1 Ну так не честно исправить его достаточно несложно
или, если уж к примеру printf — длительная операция.
К>Поскольку мониторы очень и очень распространены, специально для этого любая нормальная ОС содержит легковесные средства их реализации. При любых самых разлегковестных средствах переключение потока на несколько тактов позже жестко запланированого выиграет (в смысле наклодных расходов). и вот еще одна деталь, у этой модели небывает дедлоков С Уважением Сергей Чикирев |
| Re[4]: Атомарность | |
| От: | vladserge | ||
| Дата: | 14.10.04 08:58 |
| Здравствуйте, sereda, Вы писали: S>Здравствуйте, vladserge, Вы писали: V>>Спасибо за ответ, но на будущее просьба, до конца читать пост на который Вы отвечаете. Я ж ведь не графоман какой, то и когда пишу буквально V>>во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации. V>>то это я делаю специально для Вас. S>Спасибо Вам за то, что Вы делаете специально для меня. Я прочитал Ваш пост еще раз внимательно. Конечно, очевидно, что в цитируемой Вами фразе Вы имели в виду и synchronized в Java. Покорнейше прошу прощения за то, что не заметил сразу, и что купился на предложение обсудить вопрос. S>По теме. Если вы хотите сэкономить на context switching'e, то надо от языков требовать поддержки атомарных команд процессора вроде TestAndSet. Блокировать context switching грубой силой — это значит рисковать из-за ошибок нарушить работу не только приложения, но и всей операционки. Не думаю, что этот риск оправдан соображениями производительности. Да простят меня модераторы за частое самоцетирование, ну а что делать? понятно, что найдуться чайники которые начнут внутрь атомарного кода пихать длительные операции приводя к завесалову всей системы. Но с этим можно бороться, например подразумевая что НЕпереключения потоков внутри атомарного кода происходит только в контексте приложения, а не всей системы. А по поводу возможностей и "рисковать из-за ошибок нарушить работу не только приложения, но и всей операционки" откомпилируйте и запустите
понятно, что спички детям не игрушка. С Уважением Сергей Чикирев |
| Re[3]: Атомарность | |
| От: | WolfHound rsdn | ||
| Дата: | 14.10.04 09:09 |
| Здравствуйте, vladserge, Вы писали: V>Ну я тут не о трудностях, а об удобстве и необходимости фичи рассуждаю. Дело в том что если обсуждать фичу то нужно выяснить соотношение необходимость/цена. И в этом свете нужно обсудить сложности. V>Пока ясовсем неуверен, что это кому нибудь, кроме меня может быть интересно. а там .... будем посмотреть. Тут надо подумать о целесообразности этого. Ведь в сущьности это всеголишь глобальный(в приделах процесса)мутекс. Хотя если производительность этого мутекса будет сравнима с Interlocked функциями и этот мутекс будет всегда инициализирован то это может быть полезно. ... << RSDN@Home 1.1.4 rev. 185 >> Пусть это будет просто: просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[4]: Атомарность | |
| От: | vladserge | ||
| Дата: | 14.10.04 09:25 |
| Здравствуйте, WolfHound, Вы писали: WH>Здравствуйте, vladserge, Вы писали: V>>Ну я тут не о трудностях, а об удобстве и необходимости фичи рассуждаю. WH>Дело в том что если обсуждать фичу то нужно выяснить соотношение необходимость/цена. И в этом свете нужно обсудить сложности. Мне всеже кажется для начала нужно понять насколько это "фкусно", прежде чем стоять за этим в очередь. V>>Пока ясовсем неуверен, что это кому нибудь, кроме меня может быть интересно. а там .... будем посмотреть. WH>Тут надо подумать о целесообразности этого. Ведь в сущьности это всеголишь глобальный(в приделах процесса)мутекс. мутекс. WH>Хотя если производительность этого мутекса будет сравнима с Interlocked функциями и этот мутекс будет всегда инициализирован то это может быть полезно. ничего не понимаю С Уважением Сергей Чикирев |
| Re: Атомарность | |
| От: | GlebZ | ||
| Дата: | 14.10.04 09:30 |
| Здравствуйте, vladserge, Вы писали: Товарищ, вы отстаете от моды. Сейчас модно защищать объекты, а не просто куски кода. Наглядный пример из NET:
В результате, есть ГАРАНТИЯ правильной синхронизации объекта как внутри, так и снаружи. Защищаются именно данные а не действия над ним (и ессно в разумной степени). Защита какой-то отдельной процедуры практически никогда не нужно, и самое главное вредно. У тебя нет никакой гарантии, что при дальнейшем развитии не будет написана другая процедура работающая с этими данными. Была одна какая-то интересная книжка Рихтера (не помню названия, давно читал), где он примерно описывал работу объектов синхронизации для Win API. С уважением, Gleb. |
| Re[3]: Атомарность | |
| От: | Кодт rsdn | ||
| Дата: | 14.10.04 09:39 |
| Здравствуйте, vladserge, Вы писали: V>Ну так не честно V>исправить его достаточно несложно Ну и что получаем? Всё тот же монитор. К>>Поскольку мониторы очень и очень распространены, специально для этого любая нормальная ОС содержит легковесные средства их реализации. V>При любых самых разлегковестных средствах переключение потока на несколько тактов позже жестко запланированого выиграет (в смысле наклодных расходов). и вот еще одна деталь, у этой модели небывает дедлоков Ха! Если хочешь избежать дедлоков — заведи единственный мутекс в программе. Эффект будет абсолютно таким же, как с длинными атомарными операциями. Собственно, Interlocked операции и используют мутекс, только аппаратный. Перекуём баги на фичи! |
| Re[5]: Атомарность | |
| От: | Кодт rsdn | ||
| Дата: | 14.10.04 09:45 |
| Здравствуйте, vladserge, Вы писали: WH>>Тут надо подумать о целесообразности этого. Ведь в сущьности это всеголишь глобальный(в приделах процесса)мутекс. V>мутекс. Именно мутекс как абстракция многозадачного программирования. Какая именно реализация этого мутекса — на HMUTEX, на CRITICAL_SECTION, на семафорах — это уже нюансы. (Мне однажды пришлось реализовывать на трубках — pipe — потому что API VxWorks не поддерживает групповых операций над иными синхрообъектами). Перекуём баги на фичи! |
| Re: Атомарность | |
| От: | Sinclair rsdn | ||
| Дата: | 14.10.04 09:48 | ||
| Оценка: | 1 (1) +1 | ||
| Здравствуйте, vladserge, Вы писали: V>Привет всем! V>Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него). А ты уверен, что возникает именно такая необходимость? Дело в том, что обычно проблемы одновременного доступа относятся скорее не к атомарности какого-то фрагмента кода, а к атомарности какого-то фрагмента данных. И именно для защиты данных вводятся всякие примитивы синхронизации. Запрет на исполнение вообще любого кода во время исполнения твоего фрагмента просадит производительность. Особенно в многопроцессорных системах. Поэтому код размечают примитивами, которые позволяют выделить участки, несовместимые между собой. ... << RSDN@Home 1.1.4 beta 3 rev. 185>> |
| Re[2]: Атомарность | |
| От: | vladserge | ||
| Дата: | 14.10.04 12:22 |
| Здравствуйте, Sinclair, Вы писали: S>Здравствуйте, vladserge, Вы писали: V>>Привет всем! V>>Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него). S>А ты уверен, что возникает именно такая необходимость? Дело в том, что обычно проблемы одновременного доступа относятся скорее не к атомарности какого-то фрагмента кода, а к атомарности какого-то фрагмента данных. И именно для защиты данных вводятся всякие примитивы синхронизации. Запрет на исполнение вообще любого кода во время исполнения твоего фрагмента просадит производительность. Это почему же?????????? А я утверждаю что все произойдет с точностью до НАОБОРОТ. Производительность возрастет и вот почему. Вместо выполнения совокупности дорогостоящих процедур синхронизации, код просто эксклюзивно продолжает выполняться в плоть до выхода из атомарной секции. Порошу заметить ВЫПОЛНЯТЬСЯ, не блокироваться, а выполняться! В каком месте будет падение производительности ???? С Уважением Сергей Чикирев |
| Re[3]: Атомарность | |
| От: | Merle rsdn | ||
| Дата: | 14.10.04 12:57 |
| Здравствуйте, vladserge, Вы писали: V>Производительность возрастет и вот почему. Вместо выполнения совокупности дорогостоящих процедур синхронизации, код просто эксклюзивно продолжает выполняться в плоть до выхода из атомарной секции. Порошу заметить ВЫПОЛНЯТЬСЯ, не блокироваться, а выполняться! Это получается уже кооперативная многозадачность, а не вытесняющая. И приводит это к тому, что если твой код навернулся внутри критической секции, не важно по какой причине, расхлебывать будет вся система. Последствия подобного поддхода очень хорошо были видны на примере win16, там делалось ровно так как ты описываешь... Правда и у вытесняющей многозадачности, с блокировкой данных, есть свои подводные камни ввиде тогоже Convoy Effect'а, но с ними более-менее научились бороться... ... [ RSDN@Home 1.1.4 revision 142 ] Мы уже победили, просто это еще не так заметно... |
| P. S. | |
| От: | Merle rsdn | ||
| Дата: | 14.10.04 13:01 | ||
| Оценка: | 35 (2) | ||
| Кстати, то, что ты называешь "атомарность", скорее стоит назвать "сериализуемость" или "изолированность"... Все-таки под атомарностью обычно понимают немного другое. Атомарность — это если твой код либо выполняется целиком, либо не выполняется вообще. И мьютексы с семафорами и прочими блокировками здесь не спасут, если кусок кода навернется в середине выполнения, то об откате надо заботиться отдельно. ... [ RSDN@Home 1.1.4 revision 142 ] Мы уже победили, просто это еще не так заметно... |
| 1 2 3 4 5 |