Проблемы несинхронизированного доступа к ресурсам

[Dale]

Обсуждение статьи: «Проблемы несинхронизированного доступа к ресурсам»

[Dale]

Кто уже начал читать - обратите внимание, помимо прочего, еще и на объем.

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

[Sla]

Как для меня - слишком все разжевано.
Для начинающих? надо на ком нибудь потестить.

Если хост, получающий результаты измерения, не просто регистрирует их, а принимает на их основе решения, последствия могут быть самыми плачевными: например, хост даст команду регулятору напряжения понизить напряжение вдвое, или вовсе выполнит аварийное отключение потребителей.
Аналогичная проблема может возникнуть при медленном линейном понижении напряжения в момент перехода от 0x0100 к 0x00FF. В этом случае, как несложно догадаться, результирующее значение будет 0x0000, что тоже весьма далеко от истины.
Самое плохое в данной ситуации - это то, что ее практически невозможно диагностировать посредством отладки. Предположим, что мы получили сигнал от пользователя прибора, что он периодически дает нулевые данные, когда на самом деле провалов напряжения не наблюдалось. Мы смотрим логику прибора и делаем предположение, что проблема кроется либо в измерении, либо в передаче данных.
Мы пишем тест для измерения напряжения, который сигнализирует о нулевом результате с АЦП, подаем на вход ненулевое напряжение и неделю тестируем прибор на стенде. Результата нет - все говорит о том, что АЦП в порядке. Тогда мы тестируем подпрограмму передачи данных - подаем ей на вход различные ненулевые значения и ждем, когда на хост будет отправлен нуль. Опять тесты показывают, что все в порядке. Отчаявшись, мы пытаемся искать несуществующие проблемы в разъемах, блоке питания прибора, наводках и т.п. Все усилия тщетны - порознь все части прибора работают идеально, совместно же - дают сбой.
Тогда мы переходим к комплексному тестированию прибора на стенде, подаем на вход напряжение с реостата, который постоянно крутим взад-вперед, - и действительно видим, что изредка проскакивает ошибка. Но устойчиво воспроизвести ее не удается, последующие измерения дают нормальный результат.
Где же кроется причина наших бед? Внимательно прочитав предыдущий сценарий, мы начинаем подозревать, что причина состоит в том, что прерывание от АЦП вклинилось между чтениями младшего и старшего байтов буферной переменной. Получается, что младший байт относится к результату предыдущего измерения, а старший - к результату следующего. Похоже, что это неправильно. Вот если бы могли гарантированно считать оба байта за один раз, не прерываясь на другие действия, которые могут повлиять на их значения, мы могли бы быть уверены, что оба они относятся к одному измерению.
Итак, мы вплотную подошли к понятию атомарности, о котором уже было вскользь упомянуто в предыдущей статье.

Я бы это уменьшил в два раза

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

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


зы. это написал бы я букофф меньше.

[Dale]

Объем нормальный: по строкам не много, но очень плотно. Пока не читал - ждал завершения.

В принципе можно поставить точку и начать приводить текст в порядок. Эта логическая единица повествования завершена, следующая будет достаточно самостоятельной.

Плотность чуть понижу, разбив на пару-тройку разделов.

Если планируется еще много, я бы лучше поделила. "Многабукафф" пугает читателей...

Если не снижать детальность изложения и при этом попытаться немного оживить язык, получается больше, чем я предполагал поначалу. Я думал, что все комментарии уложатся в 3 статьи, но сейчас цифра 5 представляется более реальной. Возможно, немного погодя вдогонку пойдет еще одна - опыт применения материала в реальном проекте.

Для начинающих? надо на ком нибудь потестить.

Очень хорошая идея. Выбрать бы типичного середнячка с небольшим опытом, но с желанием узнать побольше, и прислушаться к его мнению о прочитанном.

[RXL]

АЦП требуется 2 байтовых регистра данных (младший и старший байты) для хранения 10-битного результата измерений;

Считаю, что в таких случаях лучше писать числительное.
Я имею в виду, когда используются падежи, не совпадающие по окончаниям с именительным. Или когда можно прочесть фрагмент предложения с числом двояко ("два байтовых" и "двухбайтовых"). Мелочь, но лучше читается.

Добавлено через 17 минут и 43 секунды:
Текст хорошо воспринимается.

[Sla]

Однако не все атомарные операции столь коротки и быстры. Пример более сложных атомарных операций, знакомый большинству программистов, - это транзакции. Пример простой транзакции - это перевод безналичных денег со счета покупателя на счет продавца: какая сумма снята со счета покупателя, ровно такая же должна быть добавлена на счет продавца, в противном случае транзакция не должна состояться вовсе. Ситуация, когда некоторая сумма снята с одного счета, но не попала на другой, является совершенно недопустимой. Другие процессы не должны вмешиваться в ход транзакции. В данном случае простым запретом прерываний мы уже не сможем обойтись, поскольку, во-первых, транзакция может длиться достаточно долго, и прерывания могут просто потеряться, что может оказаться недопустимым; во-вторых, само проведение транзакции может оказаться невозможным в отсутствие прерываний от внешних устройств, задействованных в транзакции.

Смешались люди, кони деньги и прерывания.

[RXL]

Слав, почему данный пример плох?

[Sla]

Как бы это объяснить... Интуитивно понятно, но объяснение не ... ну вот оно просто не вписывается и, к сожалению, добавляет заблуждений.
Давай разберем.

Пример простой транзакции - это перевод безналичных денег со счета покупателя на счет продавца: какая сумма снята со счета покупателя, ровно такая же должна быть добавлена на счет продавца, в противном случае транзакция не должна состояться вовсе.

Начало хорошее.

Ситуация, когда некоторая сумма снята с одного счета, но не попала на другой, является совершенно недопустимой.

Тут появляется нечто добавляющее неизвестность (с одного на другой)
Раз получается так, что мы пишем ( а ведь это так?) вместе, то предлагаю:
Это предложение убрать или изменить "Такая ситуация недопустима, но в пред. предложении мы уже об этом ПОЧТИ сказали.
или пред. предложение дополнить
... в противном случае транзакция не должна состояться  и такая ситуация недопустима.

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

Хорошо продолжили (почти, исключая технические подробности)

В данном случае простым запретом прерываний мы уже не сможем обойтись, поскольку, во-первых, транзакция может длиться достаточно долго, и прерывания могут просто потеряться, что может оказаться недопустимым; во-вторых, само проведение транзакции может оказаться невозможным в отсутствие прерываний от внешних устройств, задействованных в транзакции.

А здесь появились ПРЕРЫВАНИЯ с предыдущего абзаца.

В данном случае простым запретом прерываний, как в предыдущем примере, мы уже не сможем обойтись, поскольку, во-первых, транзакция может длиться достаточно долго, и прерывания могут просто потеряться, что может оказаться недопустимым; во-вторых, само проведение транзакции может оказаться невозможным в отсутствие прерываний от внешних ФАКТОРОВ, задействованных в транзакции.

Ну вот как-то так.

[Ochkarik]

После того, как некий процесс начал атомарную операцию начата, никакой другой процесс

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

и по моему ИМХО слишком длинно все.. пока дочитываешь до атомарности уже забываешь зачем она нужна)))
понятно, что перед объяснением необходимо вводить понятия потоков или прерываний. в статье они введены, но... пример актуален не для всех: для меня он слишком разжеван - дочитывать лениво. кому то наоборот, слишком далек, поэтому тоже - тоже может статься не дочитают.
наибольшее количество сил тратится на то, чтобы перевести приведенный пример в понятную для себя область, и найти свои аналогии.

PS "тост должен быть коротким. как выстрел!"

[Dale]

Кстати, да, было бы хорошо иметь подобие "ката" в живом журнале. Например, человек с опытом работы с базами данных знает, что такое транзакция, и может пропустить объяснение; а тот, кто по большей части паяет, может пожелать узнать подробнее, не прерываясь на другие источники.

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

Есть идея такого примера? Чтобы всем было понятно, что действие ни в коем случае нельзя прерывать, иначе последствия непопроавимы.

PS "тост должен быть коротким. как выстрел!"

В меру коротким... Ибо у нас уже есть такой "выстрел" про сопрограммы. В той статье все на месте, однако без комментариев оказалась почти для всех бесполезной. Если бы не длительное обсуждение, многие недоуменно пожали бы плечами и друзьям отсоветовали бы читать такую чушь.

Поставить в таких моментах линк "читать ещё".

В крайнем случае можно выкрутиться так. Раскрыть этот пункт в посте специальной темы "Комментарии к статье N". Ссылку на него поместить в статью, а в конце поста сделать ссылку "Вернуться" на анкер в статье. Немного геморройно в части согласования переходов, но в принципе работоспособно.

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

[Ochkarik]

Dale, можно просто сказать:
Допустим, есть некая структура данных.
Запрос на ее изменение - подразумевает изменение нескольких ее полей(это и есть транзакция), причем "правильной" эта структура считается только до и после завершения транзакции.
Очевидно, что изменение структуры - выполняется за несколько элементарных операций.
Промежуточное состояние - является "не валидным". Это состояние не подлежит чтению или изменению.
Ярким примером таких транзакций, являются операции со связанным списком в многопоточной программе.

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

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

[Sla]

Ochkarik, не-не-не

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


зы. Вот возникла проблемка. Обсуждение перед публикацией. С одной стороны - обсуждение темы, а с другой- стиля и смысла.
Причем - замечания, по сути дельные. Как быть???
Dale,  только не принимай  это на свой счет. Это классно, то что  написано, поверь. Оно будет востребовано   не одним "курсом".

[Ochkarik]

не-не-не! обсуждения не в укор, конечно) тема - супер!
Sla, ну... а я  например к банкам - отношения не имею) как-то купил книжку по классам С++. было невыносимо читать про примеры конвертации денег из одной валюты в другую)
впрочем, не претендую на истину... просто мне так кажется)
 

[Dale]

Ochkarik, пример со связным списком весьма хорош. Мы вставляем новый элемент в середину списка, находим предыдущий элемент, меняем в нем ссылку на новый, собираемся настроить ссылку в новом на следующий, но... наш квант времени кончился. Другой процесс ищет элемент в недоделанном списке, доходит до оборванной связи и либо уходит несолоно хлебавши, если там null, либо вовсе завершается аварийно, если там мусор.

Спасибо за идею, непременно воспользуюсь. Пример с деньгами тоже выкидывать не буду, наверняка найдутся читатели, которым бухгалтерские примеры понятнее, чем связный список. Я, сказать по правде, и сам невеликий знаток банковских дел, исключительно на житейском уровне. Это просто первое, что пришло в голову из того, что интуитивно будет понятно всем

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

Пока ставлю точку, прекращаю добавление нового материала и шлифую то, что есть. Синхронизация переползает в следующую статью.

[Dimka]

сли напряжение нарастает «медленно и линейно» (с учетом вышесказанного), настанет момент, когда младший байт результата измерения заполнится единицами, а младший — нулями:

Два раза "младший". Ноль раз "старший".

[Dale]

Два раза "младший". Ноль раз "старший".

Точно. Сотню раз вычитывали и не заметили.