Здравствуйте, Dog, Вы писали:
АКП>>>Статья:
АКП>>>Работа с потоками в C#. Часть 1.Автор(ы): Joseph Albahari
Дата: 24.03.2007
Подробно рассматривается работа с потоками — запуск, завершение, прерывание, блокировки, синхронизация, контексты синхронизации, особенности взаимодействия с апартаментами, а также потоковые возможности .NET — потоковые таймеры, пулы потоков, BackgroundWorker, асинхронные методы и делегаты.
В статье использован материал из книги Joseph Albahari, Ben Albahari "C# 3.0 in a Nutshell" — http://www.oreilly.com/catalog/9780596527570/
_FR>>Огорчает нежелание (непонимание 
) автора использовать модификатор readonly в объявлении "объекта синхронизации".
Dog>Ну так и написали бы почему необходимо использовать...
Не то, что бы необходимо, но, ИМХО, GoodPractice. Значение "объекту синхронизации" присваивается при объявлении:
object syncRoot = new object();
что бы в местах вызова перед испольхованием не беспокоиться о [потокобезопасной] инициализации. Переприсваивать значение данной переменной вредно: не удастся снять существующие локи да и где-то может запоминаться ссылка на значение данной переменной.
А раз переприсваивать значение не нужно и даже опасно, то не надо:
ни рассчитывать на разумность людей, которые будут, возможно, пользоваться вашим кодом;
ни предупреждать, например, в комментариях, что нельзя перезаписывать значение вот этой вот переменной,
когда можно попросту это запретить:
readonly object syncRoot = new object();
Теперь, даже если кому-то случайно\по незнанию захочется что-то своё записать в это поле, он узнает, что так делать нельзя.
После знакомства с последними тенденциями (Linq, Nemerle), я процентов 90 полей объявляю как readonly, ибо позволяет избежать множества проблем, самая первая из которых "не null ли в этом поле"? Во-вторых, класс, содержащий только readonly поля автоматически становится потокобезопасным. Есть и много других (большей частью эстетических) плюсов. Общее правило такое: не объявлять поле как НЕ readonly только если его ну никак нельзя сделать readonly.
Да, я знаю, что в
Framework Design Guidelines сказано, что этот модификатор рекомендуется использовать только с immutable-типами, но не согласен: модификотором readonly я защищаю не столько "содержимое", "данные" объекта, сколько ссылку на него. В C++ аналогом readonly я бы назвал
T* const field; //константный указатель
, в то время как многим хочется видеть
const T* field; //указатель на константу
