Comments 5
Получилось у нас не совсем то, что можно назвать взаимной блокировкой [...]
Но на основании рассмотренных примеров мы можем сделать вывод что использовать как термин «взаимная блокировка» для перевода термина deadlock не всегда корректно так как это только один частный случай блокировки, для которой нет или потеряна возможность снять эту блокировку.
Некорректно использовать термин "взаимная блокировка" для "не совсем того, что можно назвать взаимной блокировкой"? :) Выделенное и не является определением deadlock, которое вы забыли ввести.
Гонки можно объяснить без машинных инструкций:
if (size < capacity) {
// тут ОС отнимает управление у одного из потоков
arr[size] = value;
size++;
}
Это лучше тем, что нет путаницы с атомарными операциями, которые на отдельные инструкции не распадаются (и имеют другие особенности), но решают проблему гонки только в специфическом случае, описанном в статье.
Просто так 2 раздельные программы очень мало вероятно могут устроить друг другу блокировку, из-за особенностей работы ОС. Я не могу сейчас придумать кейс, в которой я бы написал ПО, которое взаимно блокировалось бы с каким то другим ПО на компьютере.
Описанные случаи, на мой взгляд, подходят в основном для ситуаций, когда разработчики намеренно делают работу задач в разных потоках с доступом к одним данным. В таком случае они должны понимать чем это грозит и как с этим бороться.
Соответственно чего мне не хватило в статье:
1) Описание как работает многопоточность в ОС. Несмотря на имеющиеся знания с удовольствием почитал бы, но здесь для вступления, исключительно на мой взгляд, написано слишком много, а для полноценного описания слишком мало. Все же данная темя тянет на самостоятельную статью.
2) Собственно мне не хватило информации о многопоточности в практическом программировании.
Я условно разделяю проблемы с доступом к одной области памяти разных потоков на те же категории что и при работе с одними и теми же данными в БД. Только при работе с БД я использую транзакции и проблему за меня решает СУБД в соответствии с уровнем транзакции.
А вот при написании приложения, подразумевающего совместное использование области памяти, решение проблем ложится в большей степени на мои плечи.
Поэтому здесь мне не хватило того что описаны не все проблемы.
И самое главное что не описаны какие либо паттерны их решения.
Подожду продолжения.
Очень конструктивный комментарий, благодарю! После такого комментария я чувствую себя обязанным написать продолжение (надеюсь в течении месяца), так как вы мне подсказали идею для продолжения. Идея в том, чтобы сравнить работу с БД и работу с какой-нибудь сложной аппаратной функцией, в основном с точки зрения применения-использования многопоточности. Мне теперь самому интересно возможно ли такое сравнение. Вроде как должно получиться как раз про практическое программирование. Что может иметь большее отношение к практике? Если вы напишете мне в личку я смогу предварительно отдать вам версию перед публикацией для комментариев (если сможете поучаствовать таким образом, напишите, это на ваше усмотрение таким образом).
@artofmainstreams надеюсь вам понравится:
Если поставить простой уровень, я боюсь что те кто решат что уровень сложный будут более склонны поставить минус за такую «ошибку», тогда как те кто определяет уровень как простой, когда он заявлен как сложный, скорее напишут комментарий подобный вашему.
Кстати, я надеюсь что то, что
«Уровень статьи не выглядит как сложный»
Во многом является следствием многословности, если так, то это, в общем-то то, к чему я стремился, в том числе.
А если поставить сложный уровень, то целевая аудитория увидит, что "сложно" и много текста, и пройдёт мимо. А те, кто это всё и так знают, удивятся, собственно, а к чему это всё? Я вот увидел, например, на канале Android Broadcast пост, где написано "очень много про потоки в одной статье". О, думаю, надо почитать, захожу и вижу такое заманчивое описание (почти цитата):
"Что надо знать, чтобы успешно применять многопоточность? Есть некоторые неудобные для изложения куски в разных описаниях потоков и того, что с ними связано, которые остаются нераскрытыми или вообще пропускаются."
О, интересно, какие же. Читаю, а тут лишь написано, что параллельность это всего лишь термин, который обозначает очень быстрое переключение и прерывание потоков. А ещё есть race condition и deadlock. И всё. И возникает вопрос, а на что я потратил время? Кто ЦА? Что нового узнал? Ведь есть же курс по Операционным системам от хекслета (не воспринимайте как рекламу), есть статьи на хабре:
1. https://habr.com/ru/companies/otus/articles/549814/
2. https://habr.com/ru/companies/clrium/articles/488260/
3. https://habr.com/ru/articles/40227/
И наверняка ещё куча подобных материалов, которые и нагляднее, и более насыщены информацией
Термин "многословность" тут как раз в негативном ключе, потому что кажется, будто это всё можно описать в нескольких предложениях. Самое сложное в этой статье, это понять описание примера:
"Пусть декодер некоторого JPEG-подобного формата читает данные из файла и декодирует их, записывая готовые для отображения фреймы в циркулярный буфер на 10 (на N) фреймов."
Возникают вопросы, что за JPEG-подобный формат, откуда и во что декодирует, что за отображения фреймов, что за циркулярный буфер. Была бы картинка - было бы проще (или пример упростить, или терминами не нагружать, опять же, зависит от ЦА, пример в целом понятный, но не сходу)
И напоследок. В грамотно составленной статье (как правило) в введении описывается проблема, которая решается (например, "Хочу рассказать о том, за счёт чего достигается параллельное выполнение программ..."), а в заключении краткая выжимка результатов (например, "Таким образом, мы увидели, что под параллельностью подразумевается..."). Это не то, чтобы что-то обязательное, скорее правило хорошего тона, позволяющее упростить чтение и восприятие информации
P.S. Если статья кому-то действительно окажется полезной - то я только рад. Я лишь изложил свою точку зрения, которая необязательно отражает истину
Уровень статьи не выглядит как сложный. Многословный - да, сложный - нет :) Тут же просто база описана (как мне казалось, довольно известная и почти очевидная)
Многопоточность (Multithreading) для практического программирования