LINUX.ORG.RU

История изменений

Исправление Manhunt, (текущая версия) :

А как?

Я слишком слабо понимаю твой код, чтобы рассказывать «как надо». Как раз хотел узнать, из каких соображений ты именно такие проверки расставил. Чтобы понимание свое развить немного.

А в сферической в вакууме библиотеке... Ну вот при захвате мьютекса детектить желательно оба вида переполнений, и в обоих случаях как-то сигнализировать пользовательскому коду о возникшей проблеме. Чтобы пользователь мог в ответ на это какие-то адекватные действия выполнить. (Скажем, выполнить аварийную парковку исполнительных устройств и слить дамп памяти. Или ребутнуться. Или пойти по альтернативной ветке алгоритма, не прекращая штатную работу своего устройства. В общем, это не нам решать, как он будет выкручиваться.) В случае overflow было бы достаточно вернуть какой-нибудь E_BUSY, и оставить мьютекс в старом состоянии. В случае underflow очевидно, что программа сошла с ума, и мьютекс больше никакой адекватной синхронизации уже не обеспечивает; так что нужно вернуть какой-нибудь E_UNDERFLOW, а на любые дальнейшие попытки с этим мьютексом работать возрващать E_POISONED. Подробнее про идею poison вот тут написано: https://doc.rust-lang.org/std/sync/struct.Mutex.html

Исправление Manhunt, :

А как?

Я слишком слабо понимаю твой код, чтобы рассказывать «как надо». Как раз хотел узнать, из каких соображений ты именно такие проверки расставил. Чтобы понимание свое развить немного.

Ну а в сферической в вакууме ситуации... Ну вот при захвате мьютекса детектить желательно оба вида переполнений, и в обоих случаях как-то сигнализировать пользовательскому коду о возникшей проблеме. Чтобы пользователь мог в ответ на это какие-то адекватные действия выполнить. (Скажем, выполнить аварийную парковку исполнительных устройств и слить дамп памяти. Или ребутнуться. Или пойти по альтернативной ветке алгоритма, не прекращая штатную работу своего устройства. В общем, это не нам решать, как он будет выкручиваться.) В случае overflow было бы достаточно вернуть какой-нибудь E_BUSY, и оставить мьютекс в старом состоянии. В случае underflow очевидно, что программа сошла с ума, и мьютекс больше никакой адекватной синхронизации уже не обеспечивает; так что нужно вернуть какой-нибудь E_UNDERFLOW, а на любые дальнейшие попытки с этим мьютексом работать возрващать E_POISONED. Подробнее про идею poison вот тут написано: https://doc.rust-lang.org/std/sync/struct.Mutex.html

Исходная версия Manhunt, :

А как?

Я слишком слабо понимаю твой код, чтобы рассказывать «как надо».

Вот как раз хотел узнать, из каких соображений ты именно такие проверки расставил. Чтобы понимание свое развить немного.

Ну а в сферической в вакууме ситуации... Ну вот при захвате мьютекса детектить желательно оба вида переполнений, и в обоих случаях как-то сигнализировать пользовательскому коду о возникшей проблеме. Чтобы пользователь мог в ответ на это какие-то адекватные действия выполнить. (Скажем, выполнить аварийную парковку исполнительных устройств и слить дамп памяти. Или ребутнуться. Или пойти по альтернативной ветке алгоритма, не прекращая штатную работу своего устройства. В общем, это не нам решать, как он будет выкручиваться.) В случае overflow было бы достаточно вернуть какой-нибудь E_BUSY, и оставить мьютекс в старом состоянии. В случае underflow очевидно, что программа сошла с ума, и мьютекс больше никакой адекватной синхронизации уже не обеспечивает; так что нужно вернуть какой-нибудь E_UNDERFLOW, а на любые дальнейшие попытки с этим мьютексом работать возрващать E_POISONED. Подробнее про идею poison вот тут написано: https://doc.rust-lang.org/std/sync/struct.Mutex.html