Нужно слделать систему shared/exclusive блокировок русурсов, то есть при чтение всем можно ситать, а писаттель ждёт завершение работы читателей и блокирует на время записи все остальные запросы — очень уж велосипед не хочется изобретать, по моему былы какие то паттерны для решения проблемы ...

Здравствуйте, <Аноним>, Вы писали:

А>Нужно слделать систему shared/exclusive блокировок русурсов, то есть при чтение всем можно ситать, а писаттель ждёт завершение работы читателей и блокирует на время записи все остальные запросы — очень уж велосипед не хочется изобретать, по моему былы какие то паттерны для решения проблемы ...

Если систему пессимистических транзакций обернули в паттерны — я не удивлюсь. Пока я знаю только один паттерн. Если в масштабируемых приложения можно обойтись без пессимистических блокировок, то лучше без них. Некоторый минимум был описан у Фаулера.
Лучше бы сразу сказал, какая среда разработки, какой ресурс.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, <Аноним>, Вы писали:

А>>Нужно слделать систему shared/exclusive блокировок русурсов, то есть при чтение всем можно ситать, а писаттель ждёт завершение работы читателей и блокирует на время записи все остальные запросы — очень уж велосипед не хочется изобретать, по моему былы какие то паттерны для решения проблемы ...

GZ>Если систему пессимистических транзакций обернули в паттерны — я не удивлюсь. Пока я знаю только один паттерн. Если в масштабируемых приложения можно обойтись без пессимистических блокировок, то лучше без них. Некоторый минимум был описан у Фаулера.
GZ>Лучше бы сразу сказал, какая среда разработки, какой ресурс.

GZ>С уважением, Gleb.

VС7
Есть множество ресурсов, каждый имеет свой идентификатор.
Один ресурс одновременно может читать множество читателей, а изменять — только один писатель.

Здравствуйте, <Аноним>, Вы писали:

А>Нужно слделать систему shared/exclusive блокировок русурсов, то есть при чтение всем можно ситать, а писаттель ждёт завершение работы читателей и блокирует на время записи все остальные запросы — очень уж велосипед не хочется изобретать, по моему былы какие то паттерны для решения проблемы ...

Ага, есть такой паттерн. Называется Single Writer Multiple Readers или Multiple Readers Single Writer. Ещё возможно название: "Один писатель — много читателей".

Здравствуйте, <Аноним>, Вы писали:

А>VС7
А>Есть множество ресурсов, каждый имеет свой идентификатор.
А>Один ресурс одновременно может читать множество читателей, а изменять — только один писатель.

В общем, это и есть почти название "паттерна". Или тебя интересеут архитектура реализации MRSW?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, <Аноним>, Вы писали:

А>>VС7
А>>Есть множество ресурсов, каждый имеет свой идентификатор.
А>>Один ресурс одновременно может читать множество читателей, а изменять — только один писатель.

ГВ>В общем, это и есть почти название "паттерна". Или тебя интересеут архитектура реализации MRSW?

Интересует архитектура, реализация и примеры использования

Здравствуйте, Аноним, Вы писали:

А>Нужно слделать систему shared/exclusive блокировок русурсов, то есть при чтение всем можно ситать, а писаттель ждёт завершение работы читателей и блокирует на время записи все остальные запросы — очень уж велосипед не хочется изобретать, по моему былы какие то паттерны для решения проблемы ...

Привет.

На .NETе это реализуется с помощью класса ReaderWriterLock.
В МСДН — куча примеров. Собственно, можно реализоваь по своему(мой работает более предсказуемо),
но задачка отнюдь не простая

Удачи

Здравствуйте, GlebZ, Вы писали:

GZ>Некоторый минимум был описан у Фаулера.

И я бы сказал, что вполне подробно описан.
http://martinfowler.com/eaaCatalog/
см. раздел Offline Concurrency Patterns

GZ>Пока я знаю только один паттерн. Если в масштабируемых приложения можно обойтись без пессимистических блокировок, то лучше без них.

Мне кажется более актуален паттерн "При проектировании избегайте излишней паттернизации". В хорошей архитектуре паттерны и сами обнаружатся

Здравствуйте, KKV-UANIC, Вы писали:

KU>И я бы сказал, что вполне подробно описан.
KU>http://martinfowler.com/eaaCatalog/
KU>см. раздел Offline Concurrency Patterns
Нет. Блокировки это отдельная огромная песня. Все сильно сложнее чем просто паттерны. Трудность в правильности их использовании. В определении феноменов и из изничтожении без потери масштабируемости. Если будет время, может статейку по этому поводу накропаю.

GZ>>Пока я знаю только один паттерн. Если в масштабируемых приложения можно обойтись без пессимистических блокировок, то лучше без них.
KU>Мне кажется более актуален паттерн "При проектировании избегайте излишней паттернизации". В хорошей архитектуре паттерны и сами обнаружатся
Почти соглашусь, но сейчас просматриваю одну архитектурку. 15-уровневое наследование. Много думаю.
Применимость паттернов недавно обсуждалась в философии.

С уважением, Gleb.

Здравствуйте, Aviator, Вы писали:

A>Интересует архитектура, реализация и примеры использования

Пример использования — там, где затраты на блокировки несоизмеримо малы с затратами целевых операций чтения/записи. Особенно удачно его применение в тех случаях, где информацию чаще читают, нежели изменяют. Справочные данные — идеальный пример.

Кратко устройство:

Есть 2 очереди — читателей и писателей. Пока очередь писателей пуста допускаем читателей. Как только в очереди писателей появился хоть кто-то, прекращаем допуск читателей, накапливаем их в очереди читателей. Ждем, пока все читатели освободят ресурс, после этого запускаем одного писателя. После покидания писателем ресурса запускаем всех читателей из очереди читателей. Goto begin.

Т.е. поочередно запускаем писателя/читателей.

Реализации могут быть разные. Самое простое — это интерфейс запросов ресурса с блокирующими методами. Использовать типа так:

swmrLock.EnterReader();

try {
    ...
} finally {
    swmrLock.ExitReader();   
}

Аналогично Enter/ExitWriter. Эта схема самая распространенная.
Недостаток схемы в том, что никто нам не запрещает обратиться к ресурсу напрямую в обход схемы синхронизации. Однако, в случае, где детали обращения к ресурсу скрыты инкапсуляцией, такая схема вполне имеет право на жизнь.

В публичных интерфейсах можно поступить более надежным способом — это предоставить 2 различных интерфейса для доступа к ресурсу:

// ReadOnly
public interface IReadInterface1 : IDisposable {
    int SomeAspect { get; }
}

// Common Read/Write
public interface IInterface1 : IReadInterface {
    int SomeAspect { get; set; }
}


public interface ISomeRootObj {

    IInerface1 Resource1 { get; }
    IReadInterface1  ReadResource1 { get; }

    IInerface12 Resource2 { get; }
    IReadInterface2 ReadResource2 { get; }

}

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