Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: atmoic, атомарный
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы
romez777
Приветствую.

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

Спасибо.
dxp
Цитата(romez777 @ Aug 23 2005, 07:44)
Может быть не совсем по теме конференции, но ничего ближе не нашлось smile.gif
Читал в литуратуре, но пока не догоняю смысл терминов "атомарный", "атомарность". Может кто на пальцах изложить, либо если есть документ в интернете - то с удовольствием почитаю.
*

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

В контексте процессоров понятие "атомарность" обычно применяется к инструкциям процессора. Например, в одном процессоре операция инкремента ячейки памяти делается одной инструкцией (хотя и за много тактов), а в другом это требует загрузки значения в регистр, инкремент регистра, сохранение ячейки обратно. Первая операция будет атомарной - ее нельзя прервать. Вторая - не атомарна, - если во время этой последовательности произойдет прерывание, где осуществляется доступ к инкрементируемой ячейке, то, скорее всего, будут коллизии в программе. Это, так сказать, смысл, который стоит за понятием "атомартность".

В любом случае, имеется в виду, что при атоматной операции те или иные действия выполняются неразрывно.
IgorKossak
Алаверды добавлю, что не следует слишком увлекаться атомарностью.
Особенно если внутри критической секции длинный или непредсказуемо длинный по времени исполнения код.
Иногда, чтобы временно запретить доступ к некоторым ресурсам, хорошей альтернативой атомарности служат семафоры типа mutex.
Но для каждого конкретного случая - свои решения.
Olej
Цитата(dxp @ Aug 23 2005, 08:14)
Атом - неделимый. Атомарность, соответственно, - "неделимость. В констексте ОС под атомарностью понимается ситуация, когда операция (фрагмент кода) не может быть прервана и управление отдано другому процессу (задаче). Имеет смысл в вытесняющих ОС. Например, когда надо, чтобы код выполнялся гарантировано без передачи управления, его можно поместить в критическую секцию - прерывания будут запрещены, все операции критической секции будут выполнятся одна за другой.
*


В широком смысле - всё верно, но есть ещё и узкий конкретный смысл: POSIX (расширения) определяет стандарт на группу API, называемых "атомарные операции". Т.к. я очень плотно занимался 1-1.5 года только механизмами параллелизма и синхронизации, то мне проще в объяснение просто процитировать фрагменты из моей новой книги, которая уже в сентябре выходит в издательстве "Символ-Плюс":

Цитата
Атомарные операции – это такие операции, для которых гарантируется их неделимость (атомарность, непрерываемость), даже при выполнении на симметричных мультипроцессорных платформах. Выполнение атомарных операций не разрывается даже асинхронными аппаратными прерываниями. Таким образом, эта группа операций является также и безопасной в многопоточном окружении.


Цитата
Общий вид прототипов каждой из 2-х групп атомарных операций:
void atomic_*( volatile unsigned *D , unsigned S );
unsigned atomic_*_value( volatile unsigned *D, unsigned S );

- где вместо * должно стоять имя одной из 5-и операций (таким алгоритмом и обеспечивается 10 различных атомарных функций):
add – добавить численное значение к операнду;
sub – вычесть численное значение к операнду;
clr – очистить биты в значении операнда (выполняется побитовая операция (*D) &= ~S );
set –  установить биты в значении операнда (выполняется побитовая операция (*D) |= S );
toggle – инвертировать биты в значении операнда (выполняется побитовая операция (*D) ^= S );
D – именно тот объект, над которым осуществляется  атомарная операция;
S – второй операнд осуществляемой операции.
Две формы атомарных функций для каждой операции отличаются тем, что первая из них выполняет операцию без возврата значения, а вторая – возвращая то значение, которое операнд D имел до выполнения операции (то есть прежнее значение, как это делают, например, префиксные операции инкремента и декремента: ++D и --D, в отличие от постфиксных D++ и D--).


Мне кажется, что это коротко, но достаточно ясно...

Цитата(dxp @ Aug 23 2005, 08:14)
В контексте процессоров понятие "атомарность" обычно применяется к инструкциям процессора. Например, в одном процессоре операция инкремента ячейки памяти делается одной инструкцией (хотя и за много тактов), а в другом это требует загрузки значения в регистр, инкремент регистра, сохранение ячейки обратно. Первая операция будет атомарной - ее нельзя прервать. Вторая - не атомарна, - если во время этой последовательности произойдет прерывание, где осуществляется доступ к инкрементируемой ячейке, то, скорее всего, будут коллизии в программе. Это, так сказать, смысл, который стоит за понятием "атомартность".
*


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

Цитата(IgorKossak @ Aug 25 2005, 10:18)
Алаверды добавлю, что не следует слишком увлекаться атомарностью.
Особенно если внутри критической секции длинный или непредсказуемо длинный по времени исполнения код.
Иногда, чтобы временно запретить доступ к некоторым ресурсам, хорошей альтернативой атомарности служат семафоры типа mutex.
Но для каждого конкретного случая - свои решения.
*


В API многих OS (*NIX - POSIX, собственно, во всех кроме Windows wink.gif) такого понятия как "критическая секция" - вообще отсутствует (по моему мнению оно - ещё одно уродство от MS, но это IMHO wink.gif) - любой фрагмент "обложенный" lock-unlock мютекса - уже критическая секция.
Только мютекс - никак нельзя относить к "типу семафора", это неточность: они похожи (по крайней мере с бинаными семафорами), но принципиально отличаются многим: мютекс может захватываться рекурсивно, на нём может наследоваться приорит, или мютексу может быть приписан "граничный" приоритет, ... но самое главное - у мютекса всегда есть владелец его захвативший, и только он может его освободить.

А вот собственно атомарные операции POSIX - раз в 10 быстрее операций с мютексами, и в 20-100 и более (для именованных семафоров) - операций с семафорами. Но о них часто забывается... а это - очень оптимальные решения. Даже если их использовать только для безопасных операций memcpy() в конкурентной параллельной среде:
- операция эта - прерываемая...
- одна из наиболее частых "вблизи" ядра OS - эффективность её крайне значима (неэффективность реализаций memcpy() в ARM является чуть ли не самой большой неприятностью).

Вот в самом опримитивленном виде безопасный код выполнения memcopy() хоть из 1000 конкурирующих потоков:
Код
uint8_t buf[ N ];
volatile unsigned int ind = (unsigned int)buf;
// выполняется в каждом из потоков:
memcpy( (void*)atomic_add_value( ind, how ), (void*)res, how );

- в противном случае вам пришлось бы обкладывать копирование мютексными или семафорными операциями.

P.S. саму книгу, на которую я ссылался, я не могу, к сожалению, выставить в форум: а). там >400 стр. б). меня издатели просто разорвут за такое действо wink.gif... Но кого интересуют тонкие вопросы параллелизмов - можете посмотреть раннюю редакцию этого текста (то, что было год назад sad.gif) здесь:
http://qnxclub.net/files/articles/pthread/pthread.pdf
- может кому-то окажется чем полезным.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.