[boost] Re: read/write mutexes and boost

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2003-10-20 13:20:34

There's a read-write mutex implementation thread_dev branch of CVS. See

rw_mutex.hpp at
http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/thread/?only_with_tag=thread_dev

rw_lock.hpp at
http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/thread/detail/?only_with_tag=thread_dev

rw_mutex.cpp at
http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/thread/src/?only_with_tag=thread_dev

Mike

Anthony Williams wrote:
> Daniel Spangenberg <dsp_at_[hidden]> writes:
>> Question is: Can I use the current thread library to realize a
>> read/write mutex (accepting
>> multiple readers from different threads but prevents writer from
>> access)
>> on my own?
>> If so, how should I do this? If this would help to give a more
>> precise answer: My
>> target platform is Win32, although a generic solution would be
>> wunderful, of course ;-))
>> (More worse: It must be a mutex accessible/protectable from threads
>> of different
>> processes...).
>
> I have an implementation of a read/write mutex for win32, which uses
> a critical section and a semaphore along with a writer flag and a
> reader count (and another critical section so the test harness can
> get at the reader/writer info). It may not be the most efficient
> implementation, but I am fairly sure that it works correctly.
>
> I use native Win32 facilities, but I expect the code could be changed
> to boost::thread facilities very easily. Also, on systems which
> support such a concept natively, I would hope that my code could be
> converted into a wrapper for the native support.
>
> Making it work across processes would be tricky --- you would have to
> use a named mutex and named semaphore, and that requires generating
> names known to both the processes involved, but which don't clash
> with the names of any other mutexes or semaphores in the system.
>
>> My assumption is, that I could use *one* single mutex for both read
>> and
>> write access
>> and probably a kind of reader counter (similar to recursive_mutex),
>> is
>> that right?
>
> The logic I use is this:
>
> Initially, the writing flag is clear, the reader count is zero, the
> critical section is unlocked and the semaphore is signalled.
>
> To acquire a write lock, the code locks the CS and checks the reader
> count. If the reader count is non zero, unlock the CS and wait for
> the semaphore to be signalled, then repeat until the reader count is
> zero. Leave the CS locked and set the writer flag.
>
> To release the write lock, signal the semaphore, clear the write flag
> and unlock the CS.
>
> To acquire a read lock, lock the CS and increment the reader count.
> Clear the semaphore.
>
> To release a read lock, lock the CS, decrement the reader count and
> signal the semaphore if the reader count is now zero.
>
> Note that a write lock holds the CS for the duration, since there can
> only be one write lock. This causes all read requests to queue. OTOH,
> the read lock only holds the CS whilst it does the lock/unlock
> operation, since there is no clear owner of the CS with the multiple
> readers, as the first to acquire will not necessarily be the last to
> release.
>
> I can post the code if you wish. Maybe it could be added to
> Boost.Threads
>
> Anthony