Модель приложений .NET. Потоки.
Перевод такой:
Добавлена Бостонская Президентская гостиница с одним номером. Поток 13 стартовал новый поток. Поток 28 стартовал. Поток 29 стартовал. Резервирование для Клиента 1 в Бостонской Президентской гостинице на 12/12/2001 12:00:00 AM в течение 3 дней Поток 28 вошел в Брокер::Резерв Поток 28 находит, что номер доступен в Брокер::Резерв Поток 28 вышел из Брокер::Резерв Резервирование для Клиента 1 было заказано Reservationld = 1 ReservationRate = 10000 ReservationCost = 30000 Комментарий = OK Резервирование для Клиента 2 в Бостонской Президентской гостинице на 12/13/2001 12:00:00 AM в течение 1 дня Поток 29 вошел в Брокер::Резерв Поток 29 вышел из Резерв. Резервирование для Клиента 2 не могло быть заказано Номер не доступен Сделано!
Как и в предыдущем случае, второй поток не может выполнить метод Reserve (Резерв), пока поток, который начал выполнение первым, не закончится. Номер резервируется только раз.
Отличие этого автоматического подхода заключается в том, что синхронизируется доступ ко всем методам класса независимо от того, нуждаются они в этом или нет. Доступ к другим совместно используемым данным с помощью других методов данного класса также блокируется. Такое поведение получается независимо от желания программиста.
Обращаем внимание читателя на то, что в любой определенный момент только один поток может выполнять какой-нибудь метод класса. Предположим, что мы добавляем к классу еще один метод под названием CancelReservation. Если какой-нибудь поток вызвал метод CancelReservation, то блокируются все другие потоки, делающие попытки выполнять другие методы класса, включая и метод MakeReservation.
Для программы, которая производит резервирование номеров в гостинице, это желательное поведение, так как нежелательно, чтобы метод MakeReservation пытался использовать структуру данных в момент ее изменения. В некоторых ситуациях, однако, такое поведение нежелательно и уменьшает производительность из-за ненужного блокирования. Увеличение числа конфликтов может стать помехой для масштабирования, так как блокируются не только определенные, нуждающиеся в синхронизации области.
Использовать атрибуты проще, чем критические секции. Не нужно заботиться о подробностях правильной реализации синхронизации. С другой стороны, в результате мы получаем поведение, которое уменьшает масштабируемость. Разные приложения и различные части одного и того же приложения могут получать выгоду от использования того подхода, который в данном конкретном случае имеет больше смысла.