Возможно, стоит пояснить разницу между синхронизацией из thread/process-safe и синхронизацией с помощью Lock🤔
Наша задача — заставить разные процессы и потоки обращаться к базе данных (или любым другим ресурсам) последовательно. Чтобы не случилось так называемого race condition, то есть состояние гонки. Это когда разные потоки или процессы пытаются одновременно что-то сделать с одним и тем же ресурсом.
В этом случае нам нужна какая-то логика ограничения. Пока один процесс не завершил своё действие, другие не могут получить доступ к ресурсу.
Так вот, thread-safe и process-safe означает что отдельно взятые операции записи в БД гарантированно будут последовательны. Запросы из разных процессов или потоков выстроятся в очередь и не будут мешать друг другу. Лучше всего когда этот блок реализован на уровне БД в виде атомарных операций или ещё как-то.
Но зачем нам тогда еще дополнительный Lock?
Этот способ синхронизации используется когда процесс никак не укладывается в одно действие и должен сделать множество операций прежде чем дать доступ следующему. В этом случае процесс ставит некий глобальный Lock на ресурс и никто другой, даже получив законное право на доступ, не может ничего сделать. Все ждут пока этот Lock не будет снят.
Это решается на уровне приложения и правильность реализации полностью в вашей ответственности. Например, если забыли разблокировать или сделали перекрёстный Lock (Deadlock как на картинке), то всё зависнет в бесконечном ожидании.
#basic
🧭 Прогноз погоды для #DDay, изменивший мировую историю 🧭
5 июня 1944 года, 80 лет назад, в маленьком домике недалеко от Портсмута группа метеорологов представила генералу Эйзенхауэру один из важнейших прогнозов погоды в 📍истории. От их слов зависели жизни сотен тысяч солдат и исход Второй мировой войны.
«Просто назовите нам пять ясных, тихих дней, и мы начнем», сказали генералы союзных войск метеорологам, когда планировали открытие Второго фронта — высадку в Нормандии. Столетние погодные записи свидетельствовали о том, что надежды на такое не было.
Что делало этот прогноз уникальным? Впервые была применена система тройной 🔺проверки – три независимые метеорологические группы анализировали данные: британские ВВС, Королевский военно-морской флот и американские метеорологи. Каждая команда работала изолированно, чтобы избежать взаимного влияния, и только затем капитан Джеймс Стагг сводил их выводы воедино.
Операция «Оверлорд» была запланирована на 5 июня, но синоптики обнаружили приближающийся шторм в Ла-Манше. Несмотря на мнения некоторых генералов, метеорологи настояли на переносе операции на 6 июня, предсказав кратковременное улучшение погоды. Наконец, на непростом совещании в 4 часа утра, Эйзенхауэр 🔜 отложил операцию на 24 часа — всего за два часа до отплытия основных сил.
Это было смелое решение — на карту была поставлена вся операция. Немцы считали шторм непреодолимым препятствием и не ожидали атаки. Когда 6 июня наступило предсказанное «окно» 🪟 в погоде, союзники начали высадку и заставили противника врасплох: Роммель отправился домой в отпуск, а три немецкие генерала проводили симуляцию возможного вторжения в Ренне.
Для Советского Союза успешная высадка союзников стала долгожданным открытием Второго фронта, приблизившего окончание войны. История Дня «Д» напоминает нам: иногда самые незаметные герои — метеорологи с их картами 🗾 и тщательной перепроверкой данных — могут изменить ход истории.
Сегодня мы вспоминаем всех тех, кто тогда, преодолевая невероятные трудности, приближал день мира в Европе. И всех тех, кто в этой борьбе принес самую высокую жертву — свою жизнь.
Узнайте больше о самом важном прогнозе: https://www.youtube.com/watch?v=98PI_mlJJM8
#DDay#DDay81#VEDay#VEDay80