Зачем вам нужен объект блокировки для C #?

Question

Иногда вы можете повторно использовать сам объект для блокировки, но довольно часто рекомендуется в любом случае использовать другой объект.

Разве у нас нет гораздо большей безопасности типов и гораздо лучшего намерения, если быпросто быть ключевым словом для блокировки?

private object _MyLock = new object();

// someone would now be able to reassign breaking everything
_MyLock = new object();

lock ( _MyLock )
    ...

VS

private lock _MyLock;

// compiler error
_MyLock = new object();

lock ( _MyLock )
    ...

До того, как я получу отрицательные отзывы, вы не можете догадаться о чьем-то намерении: я почти уверен, что у разработчиков языка было хорошеепричина и есть более знающие кодеры здесь, что теперь почему.Я прошу это, чтобы понять лучше принципы программирования.

Answer 1

Обратите внимание, что, используя объект в качестве монитора, вы уже можете делать все, что вы можете делать с любым другим объектом: передавать ссылки, чтобы несколько классов могли совместно использовать один и тот же монитор, хранить их в массивах, хранить их внутри других данныхструктуры.

Если бы у вас был специальный тип объявления для блокируемого, вам понадобился бы специальный синтаксис для передачи его функции, хранения ссылки на него внутри другого экземпляра, ассоциирования его с типом вместо экземпляра.создание массивов (например, для операции LockMany) и т. д.

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

Answer 2

Разве у нас нет гораздо большей безопасности типов и гораздо лучшего намерения, если бы было просто ключевое слово для блокировки?

Речь совсем не о безопасности типов.Речь идет о потоке безопасности.

Иногда это означает запуск одного и того же кода в одном lock снова и снова.Возможно, у вас есть один большой массив, в котором для некоторых ваших операций может понадобиться поменять местами два элемента, и вы хотите убедиться, что во время обмена все синхронизировано.В таком контексте даже простое ключевое слово lock само по себе, где объект создается для вас за кулисами, может быть достаточно хорошим.

Иногда вы разделяете объект среди очень разных наборовкод.Теперь вам нужно несколько lock секций, которые координируются с использованием общего объекта.В этом случае код, о котором вы говорите, кажется, имеет смысл.Позволить компилятору создать объект блокировки для вас недостаточно, потому что различные секции lock не будут координироваться, но вы также хотите убедиться, что общий объект блокировки зафиксирован и не изменяется каким-либо образом.Например, возможно, вы работаете с массивом с несколькими потоками, и у вас есть различные операции, которые могут изменить значение общего индекса, указывающее, какой элемент считается текущим или активным.Каждая из этих операций должна блокировать один и тот же объект.

Но иногда вы разделяете несколько экземпляров объекта (часто одного и того же типа) между несколькими наборами кода.Подумайте о модели производитель / потребитель, в которой нескольким потребителям из разных потоков необходимо координировать доступ к общей очереди, а сами потребители являются многопоточными.В этом случае один общий объект блокировки может быть полезен для извлечения элемента из очереди, но один общий объект в разных разделах потребителя может стать узким местом для приложения.Вместо этого вам нужно блокировать только один раз для каждого активного объекта / потребителя.Вам необходим раздел lock, чтобы принять переменную, которая указывает, какой объект нуждается в защите, без блокировки всего набора данных.

Answer 3

Одним из решений может быть определение объекта блокировки как readonly.

static readonly object lockObject = new object();

. В этом случае компилятор предотвращает обновление и назначение нового объекта lockobject.

.