0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: разработка на с++, программирование на с++, многопоточное программирование, lock-free алгоритмы и структуры данных, lock-free, атомарность, атомарные процессы, compare and swap</p>
1
<p>Теги: разработка на с++, программирование на с++, многопоточное программирование, lock-free алгоритмы и структуры данных, lock-free, атомарность, атомарные процессы, compare and swap</p>
2
<p>В одной из прошлых заметок мы приводили пример<strong>конкурентной обработки</strong>двух конфликтных запросов, которые возникли в связи с одновременным бронированием одного и того же номера двумя разными менеджерами отеля. Такая ситуация стала возможной из-за того, что бронирование номера не является<strong>атомарным</strong>по своей сути, не защищено от конкурентного доступа. Как правило, существует несколько путей решения.</p>
2
<p>В одной из прошлых заметок мы приводили пример<strong>конкурентной обработки</strong>двух конфликтных запросов, которые возникли в связи с одновременным бронированием одного и того же номера двумя разными менеджерами отеля. Такая ситуация стала возможной из-за того, что бронирование номера не является<strong>атомарным</strong>по своей сути, не защищено от конкурентного доступа. Как правило, существует несколько путей решения.</p>
3
<h2>Блокировка</h2>
3
<h2>Блокировка</h2>
4
<p>Самое простое, на первый взгляд, решение. Мы разрешаем пользоваться системой бронирования<strong>лишь одному человеку</strong>единовременно. Второй пользователь в этом случае не сможет войти в систему до того момента, пока первый пользователь не обновит данные путём сохранения внесённых изменений. Всё бы ничего, но номеров много, причём каждый из них независим от других. А если у нас целая сеть отелей и большой штат сотрудников, которые находятся в разных точках гостиничного комплекса? Кому-нибудь<strong>вечно придётся ожидать доступа</strong>? Пожалуй, вариант априори неприемлем. Очередной пример<strong>сверхсуровой атомарности</strong>- монопольный доступ, когда бронирование осуществляет только администратор. Тут вообще без комментариев.</p>
4
<p>Самое простое, на первый взгляд, решение. Мы разрешаем пользоваться системой бронирования<strong>лишь одному человеку</strong>единовременно. Второй пользователь в этом случае не сможет войти в систему до того момента, пока первый пользователь не обновит данные путём сохранения внесённых изменений. Всё бы ничего, но номеров много, причём каждый из них независим от других. А если у нас целая сеть отелей и большой штат сотрудников, которые находятся в разных точках гостиничного комплекса? Кому-нибудь<strong>вечно придётся ожидать доступа</strong>? Пожалуй, вариант априори неприемлем. Очередной пример<strong>сверхсуровой атомарности</strong>- монопольный доступ, когда бронирование осуществляет только администратор. Тут вообще без комментариев.</p>
5
<h2>Подход Lock-Free</h2>
5
<h2>Подход Lock-Free</h2>
6
<p>При его реализации можно сделать так, чтобы операции не мешали друг другу. Но чтобы всегда можно было понять, что что-то пошло не так. Лучший способ это реализовать - выполнить проверку наличия<strong>параллельных операций</strong>, например, с помощью счётчика изменений. Но вот тут-то и кроется подвох. Дело в том, что процесс проверки тоже<strong>неатомарен</strong>, ведь он состоит из двух действий: проверка, как таковая, плюс непосредственно внесение изменений. И между выполнением этих двух действий всегда может кто-то "вклиниться", что сведёт на нет наши усилия.</p>
6
<p>При его реализации можно сделать так, чтобы операции не мешали друг другу. Но чтобы всегда можно было понять, что что-то пошло не так. Лучший способ это реализовать - выполнить проверку наличия<strong>параллельных операций</strong>, например, с помощью счётчика изменений. Но вот тут-то и кроется подвох. Дело в том, что процесс проверки тоже<strong>неатомарен</strong>, ведь он состоит из двух действий: проверка, как таковая, плюс непосредственно внесение изменений. И между выполнением этих двух действий всегда может кто-то "вклиниться", что сведёт на нет наши усилия.</p>
7
<h2>Compare and Swap</h2>
7
<h2>Compare and Swap</h2>
8
<p>Наилучший вариант в нашем случае -<strong>Compare and Swap (CaS)</strong>- та самая операция, которая является краеугольным камнем<strong>Lock-Free алгоритмов</strong>. CaS - это операция замены значения элемента с проверкой его предыдущего значения. Если наше предположение о предыдущем значении верно (то есть никто не успел поменять значение элемента до нас), то замена происходит. Иначе - операция<strong>CaS</strong>выполнена не будет, и мы поймем, что что-то пошло не так - элемент имеет какое-то другое значение.</p>
8
<p>Наилучший вариант в нашем случае -<strong>Compare and Swap (CaS)</strong>- та самая операция, которая является краеугольным камнем<strong>Lock-Free алгоритмов</strong>. CaS - это операция замены значения элемента с проверкой его предыдущего значения. Если наше предположение о предыдущем значении верно (то есть никто не успел поменять значение элемента до нас), то замена происходит. Иначе - операция<strong>CaS</strong>выполнена не будет, и мы поймем, что что-то пошло не так - элемент имеет какое-то другое значение.</p>
9
<p>Здесь важно то, что проверка и замена представляют собой<strong>единое действие</strong>, то есть процесс является<strong>атомарным</strong>, а между проверкой и заменой никто вклиниться не сможет. В этом и заключается смысл<strong>Compare and Swap</strong>.</p>
9
<p>Здесь важно то, что проверка и замена представляют собой<strong>единое действие</strong>, то есть процесс является<strong>атомарным</strong>, а между проверкой и заменой никто вклиниться не сможет. В этом и заключается смысл<strong>Compare and Swap</strong>.</p>
10
<p>Ознакомиться с подробностями работы<strong>Lock-Free алгоритмов</strong>на примере рабочего кода вы сможете на наших занятиях по курсу "<a>Разработчик С++</a>". Ждём вас в ближайшей группе!</p>
10
<p>Ознакомиться с подробностями работы<strong>Lock-Free алгоритмов</strong>на примере рабочего кода вы сможете на наших занятиях по курсу "<a>Разработчик С++</a>". Ждём вас в ближайшей группе!</p>
11
11