Синхронизация доступа
От: Ktirf  
Дата: 09.09.01 22:37
Оценка:
Возможно, я не совсем правильно выбрал форум, но думаю, сия задача будет интересна даже тем, кто пишет на Бейсике под Unix ;)

Задача следующая. Имеется некоторый объект, доступ к которому возможен одним из двух способов: либо R/O, либо R/W. Требуется синхронизировать доступ по вполне очевидному сценарию: если кто-то пытается обратиться к объекту по R/W, объект должен быть свободен; если кто-то пытается обратиться к объекту по R/O, в объект не должны в этот момент записывать. Классическая схема разлочки, используемая везде. Внимание, вопрос: как реализовать эту схему? Нужно сделать так, чтобы пишущие/читающие агенты могли ждать, когда объект освободится (WaitForSingleObject или аналогично). Лично я споткнулся на том, что писателю нужно ждать, пока все читатели не отпустят объект. Получается что-то вроде семафора наоборот: объект синхронизации должен быть в сигнальном состоянии, когда его счетчик равен нулю. Как его написать?
Re: Синхронизация доступа
От: Ktirf  
Дата: 09.09.01 22:45
Оценка:
Да, было бы очень круто сделать этот объект синхронизации так, чтобы его можно было вписать в WaitForSingleObject 8-) (либо унаследовать от MFC'шного CSyncObject, но это хуже)
Re: Синхронизация доступа
От: Alex Fedotov США  
Дата: 10.09.01 03:29
Оценка:
Здравствуйте Ktirf, вы писали:

K>Задача следующая. Имеется некоторый объект, доступ к которому возможен одним из двух способов: либо R/O, либо R/W. Требуется синхронизировать доступ по вполне очевидному сценарию: если кто-то пытается обратиться к объекту по R/W, объект должен быть свободен; если кто-то пытается обратиться к объекту по R/O, в объект не должны в этот момент записывать. Классическая схема разлочки, используемая везде. Внимание, вопрос: как реализовать эту схему? Нужно сделать так, чтобы пишущие/читающие агенты могли ждать, когда объект освободится (WaitForSingleObject или аналогично). Лично я споткнулся на том, что писателю нужно ждать, пока все читатели не отпустят объект. Получается что-то вроде семафора наоборот: объект синхронизации должен быть в сигнальном состоянии, когда его счетчик равен нулю. Как его написать?


Эта задача разобрана в книге Рихтера.

Здесь ее решение в моем исполнении:
http://www.codeguru.com/cgi-bin/bbs/wt/showpost.pl?Board=vc&Number=196879&page=&view=&sb=
-- Alex Fedotov
Re: Синхронизация доступа
От: Gambler  
Дата: 10.09.01 07:47
Оценка:
Здравствуйте Ktirf, вы писали:

K>Возможно, я не совсем правильно выбрал форум, но думаю, сия задача будет интересна даже тем, кто пишет на Бейсике под Unix ;)


K>Задача следующая. Имеется некоторый объект, доступ к которому возможен одним из двух способов: либо R/O, либо R/W. Требуется синхронизировать доступ по вполне очевидному сценарию: если кто-то пытается обратиться к объекту по R/W, объект должен быть свободен; если кто-то пытается обратиться к объекту по R/O, в объект не должны в этот момент записывать. Классическая схема разлочки, используемая везде. Внимание, вопрос: как реализовать эту схему? Нужно сделать так, чтобы пишущие/читающие агенты могли ждать, когда объект освободится (WaitForSingleObject или аналогично). Лично я споткнулся на том, что писателю нужно ждать, пока все читатели не отпустят объект. Получается что-то вроде семафора наоборот: объект синхронизации должен быть в сигнальном состоянии, когда его счетчик равен нулю. Как его написать?


И чё?
Какие проблемы то?
Если хотишь читать то читай если хотиш писать то сначала завладей а потом пиши.

Какие проблемы?
-------------------------------------------------------------------

Вызывает презедент к себе коров и говорит:
— Ну, что будем сдавать, молоко или мясо?
(с) Г. Явлинский TV6 — Герой дня (18.04.2002)
Re[2]: Синхронизация доступа
От: Ktirf  
Дата: 10.09.01 08:56
Оценка:
Здравствуйте Alex Fedotov, вы писали:

AF>Эта задача разобрана в книге Рихтера.


AF>Здесь ее решение в моем исполнении:


(Уныло) Спасибо, конечно... В общем-то, такой код я и сам написал. Я просто думал, что есть какие-то элементы WinAPI, которые упрощают организацию подобного доступа. Видимо, нету. А жаль.

В любом случае спасибо.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.