D const enables multi-reader synchronization

["Jérôme M. Berger"]

Tomek Sowiński wrote:
> 3. If answer to 2. is yes, how do we tackle write-starvation? In a
> read-mostly scenario the mutating thread may be held up forever.
> 
	I'd say that as soon as someone requests the write lock, nobody can
get the read lock anymore. Then when the current readers release the
lock, the writer gets it. So you can have the following sequence of
events:

1. R1 requests the read lock and gets it;
2. R2 requests the read lock and gets it;
3. W1 requests the write lock and waits;
4. R3 requests the read lock and waits;
5. R4 requests the read lock and waits;
6. R1 and R2 release the lock, W1 gets it;
7. W2 requests the write lock and waits;
8. W1 releases the lock, R3 and R4 get it (since they requested the
lock before W2);
9. R5 requests the read lock and waits (since W2 is already waiting
for the write lock);
10. R3 and R4 release the lock, W2 gets it;
11. W2 releases the lock, R5 gets it.

	Of course, this is not optimal: it is conceivable that R3 could
have gotten the lock, done whatever it had to do and released the
lock before R1 and R2. However, I believe it is the best compromise:
it still allowed R1 and R2 to access the object simultaneously,
while at the same time ensuring that write starvation cannot occur.

		Jerome
-- 
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20100614/e0be1594/attachment.pgp>