"Dave Handley" <dave.handley@morganstanley.com> wrote in message news:41B9816CBF7F0249AEED3F2B4FE1A5A958B8@lnpdtdc1.pdt.ms.com...
Date: Tue, 24 Oct 2006 09:03:13 -0700 From: "Chris Thomasson" <cristom@comcast.net> Subject: Re: [boost] A fast-pathed rw-mutex algorithm for Boost... To: boost@lists.boost.org Message-ID: <ehlcp0$3vf$1@sea.gmane.org>
[...]
I've not looked at the code in question - but the way I see it a well behaved readers/writer lock should do the following:
1) If a single writer is waiting, further attempts to acquire read locks should wait until the writer has locked and unlocked. 2) If a second writer starts to wait, it should not prevent other read locks getting involved - and should only start to block new read locks at the point at which it acquires the lock.
If you do this (and have reasonable selection of which waiting thread is serviced first) then you can avoid starvation on both sides under all circumstances.
My current code gives writers priority because there is not going to be a lot of frequent writes anyway... However, it would be trivial to make it work like you describe...
This can easily be done with atomics and a single 32 bit ref count.
Yeah... However, I don't really have any problems with using DWCAS when I am not dealing with pointers... A DWCAS algorithm that does not deal with pointers on a 32-bit system is 100% compatible with normal CAS on a 64-bit system... This is fairly portable because nearly all 32-bit architectures have a DWCAS, but hardly any 64-bit architecture has DWCAS; as long as you don't use pointers your okay: http://groups.google.com/group/comp.arch/browse_frm/thread/71f8e0094e353e5 ;^)