Реализовать аппаратную блокировку мультиплексора в C #

Question

Мы используем физический (де) мультиплексор в нашей системе (с временным разделением, один вход, несколько выходов).

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

Для этого сценария в настоящее время мы используем оператор lock, как в

public void DoSomething(Action action, int channel)
{
    lock(_lock)
    {
        _multiplexer.Route(channel);
        action();
    }
}

Используется lock, соответствующийв этом случае использования или есть другие подходы для блокировки аппаратного устройства?Я часто читаю

Держите замки крепко

и

Никогда не выполняйте произвольные действия внутри замка

Применяются ли эти правила в этой ситуации?

Answer 1

Да, это правильное использование замков (в отличие от других механизмов блокировки).Однако некоторые могут утверждать, что следует использовать другую межпроцессную блокировку типа, например, именованный мьютекс, потому что, если несколько процессов могут быть запущены, они могут одновременно получить доступ к оборудованию, что может повредить данные.

«Держите замки крепкими» обычно означает, что вы должны быть уверены, что не выполняете ненужную обработку, удерживая блокировку.Например, если вам нужно выделить некоторое пространство для размещения данных, это обычно можно сделать вне блокировки.Второе правило - избегать тупиковых ситуаций.Например, если внутри действия, переданного в DoSomething, код должен был заблокировать другую блокировку , а в некоторых случаях другой код должен был получить доступ к этой блокировке перед вызовом DoSomething, если эти два пути кодаесли бы он работал одновременно, вы бы зашли в тупик (один удерживал этот замок и ждал другого, а другой удерживал другой замок и ждал этого).Если разработчики, использующие этот код, имеют дисциплину, чтобы никогда не брать никаких блокировок или выполнять ненужную обработку в указанном действии, все будет работать нормально, но это большая проблема, если.

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