Comments 10
Интересно, что ситуация разорванной записи может возникнуть и на одном ядре: системное прерывание — скажем, для запланированной смены контекста потока — может возникнуть между внутренними операциями 32-битного сохранения! В этом случае, когда поток возобновит свою работу, он начнет выполнять инструкцию strd заново.
Не хватает вывода о том, что несмотря на это, с точки зрения потока, выполняющего эту инструкцию, она выполнится атомарно — разорванного чтения не будет, будет получено одновременное состояние регистров.
Очень не хватает совместного рассмотрения атомарных операций вместе с барьерами памяти. Потому как они работают правильно только совместно.
Если доступ к переменной осуществляется из двух мест, то операции над такой переменной нельзя рассматривать с точки зрения одного потока в принципе.
Взаимодействие атомарных операций и барьеров будет рассмотрено в другой статье, это только вступление.
Взаимодействие атомарных операций и барьеров будет рассмотрено в другой статье, это только вступление.
Если доступ к переменной осуществляется из двух мест одновременно, мы говорим, что это баг, а код выбрасываем.
Все ухищрения под названием «мьютексы», «критические секции», «атомарные операции», «сравнение-с-обменом» нужны как раз для того, чтобы исключить одновременный доступ к переменным и превратить его в последовательный, обозримый одним потоком. А остальные пусть изволят стоять или вертеться на спинлоке.
Все ухищрения под названием «мьютексы», «критические секции», «атомарные операции», «сравнение-с-обменом» нужны как раз для того, чтобы исключить одновременный доступ к переменным и превратить его в последовательный, обозримый одним потоком. А остальные пусть изволят стоять или вертеться на спинлоке.
Вместо «одновременный» мне правильнее бы было использовать слово «конкуррентный». И если уж на то пошло, атомарность важна для неблокирующих алгоритмов, где использование мьютексов и спин-локов стремится к нулю. Если же остальные потоки ждут за барьерами, то атомарность отдельных операций вообще не имеет значения.
Многопоточность и конкуренция за данные — настолько тонкие темы, напичканные нюансами, что одно неправильно вставленное (того хуже, переведенное) слово может все испортить. Вот и сейчас я так понимаю под «барьерами» у вас «примитивы синхронизации», а не «барьеры памяти»?
Для неблокирующих алгоритмов важна связка «атомарность», «правильная работа с барьерами памяти», «тесты производительности в сравнении с мьютексами». Обидно же будет создателю неблокирующего алгоритма, когда дуболомный вариант на мьютексах не окажется заметно медленней его произведения искусства.
Для неблокирующих алгоритмов важна связка «атомарность», «правильная работа с барьерами памяти», «тесты производительности в сравнении с мьютексами». Обидно же будет создателю неблокирующего алгоритма, когда дуболомный вариант на мьютексах не окажется заметно медленней его произведения искусства.
Я с вами абсолютно согласен. Но могу заметить, что статья предназначена для людей, которые не очень разбираются в этих вопросах (о чем сказано в конце её кусивом), поэтому она максимально проста и охватывает одну тему. Я планирую перевести еще несколько статей этого автора, там, поверьте, есть очень нетривиальные вещи, которые я сам не до конца понимаю, поэтому я и взялся за перевод блога.
Вы начали хорошее дело, продолжайте. Постарайтесь при этом учесть например этот цикл статей.
Понимаю, что это из песочницы, но всё же напишите в самом верху статьи, что это перевод. Можно просто ссылку на оригинал перетащить снизу вверх. А то я уж подумал, что сам автор Mintomic к нам зашёл. Статья интересная и очень нужная на Хабре, продолжайте переводить.
Изучаю сейчас тему атомиков, в т.ч. ищу инфу на Хабре. Кому интересно, вот из более свежего тоже отличный материал: https://habr.com/ru/company/ncloudtech/blog/694284/
Only those users with full accounts are able to leave comments. Log in, please.
Атомарные и неатомарные операции