Существует ли глобальная именованная блокировка читателя/писателя?
Потому что они реализованы по-разному в результате кода IL (и машинного языка). Свойство Automatic все еще отображается как публичный getter и setter, тогда как публичное поле - это просто одно поле.
Таким образом, реализация свойства auto позволяет вам в какой-то более поздний срок изменить внутреннее поведение либо getter, либо setter (например, добавление валидатора) без повторной компиляции или re = кодирования любых зависимых классов, которые его используют ...
3 ответа
Возможно моделировать блокировку читателя/устройства записи с помощью Взаимного исключения и Семафора. Я не сделал бы этого, если бы я должен был получить доступ к нему тысячи времен в секунду, но для десятков или возможно сотни времен в секунду, то это должно работать просто великолепно.
Эта блокировка предоставила бы эксклюзивный доступ 1 устройством записи или параллельный доступ N (возможно большой, но необходимо определить его), читатели.
Вот то, как это работает. Я буду использовать 10 читателей в качестве примера.
Инициализируйте именованное Взаимное исключение, первоначально несообщенное, и именованный Семафор с 10 слотами:
Mutex m = new Mutex(false, "MyMutex");
Semaphore s = new Semaphore(10, 10, "MySemaphore");
Получите блокировку читателя:
// Lock access to the semaphore.
m.WaitOne();
// Wait for a semaphore slot.
s.WaitOne();
// Release mutex so others can access the semaphore.
m.ReleaseMutex();
Блокировка читателя выпуска:
s.Release();
Получите блокировку устройства записи:
// Lock access to the seamphore
m.WaitOne();
// Here we're waiting for the semaphore to get full,
// meaning that there aren't any more readers accessing.
// The only way to get the count is to call Release.
// So we wait, then immediately release.
// Release returns the previous count.
// Since we know that access to the semaphore is locked
// (i.e. nobody can get a slot), we know that when count
// goes to 9 (one less than the total possible), all the readers
// are done.
s.WaitOne();
int count = s.Release();
while (count != 9)
{
// sleep briefly so other processes get a chance.
// You might want to tweak this value. Sleep(1) might be okay.
Thread.Sleep(10);
s.WaitOne();
count = s.Release();
}
// At this point, there are no more readers.
Блокировка устройства записи выпуска:
m.ReleaseMutex();
Хотя хрупкий (каждый процесс с помощью этого лучше имеют то же число для семафорного количества!), я думаю, что это сделает то, что Вы хотите, пока Вы не пытаетесь поразить его слишком трудно.
Я не думаю, что существует что-либо, что удовлетворяет Ваши потребности, как указано (хотя я оставляю за собой право быть неправильным).
Вы могли служить файлу с помощью сервиса. Это решает две проблемы. Во-первых, как Вы заявили, проблема параллелизма. Кроме того, даже если можно достигнуть синхронизации, это становится более трудным и ужасным при запуске выравнивания нагрузки. Обслуживание файла с помощью сервиса будет, вероятно, стоить Вам в производительности, но решает Вашу проблему синхронизации.
Как насчет этого? Не подавайте файлы. Подайте копии из файлов. Когда необходимо внести изменение, создать новый файл и подать копию этого с тех пор.