search

basvandijk / concurrent-extra

Extra concurrency primitives
Other
17 stars 5 forks source link

ReadWriteLock fairness #7

Open waldheinz opened 10 years ago

waldheinz commented 10 years ago

The fairness of the ReadWriteLock should be documented. From my observations it seems it is not fair (my writers pile up until there are no readers left). And, if at all possible, it would be really nice if there was a "fair" version of the ReadWriteLock.

roelvandijk commented 10 years ago

You are right. There is a situation where a writer will never get access as long as there are enough readers acquiring the read lock. I consider this to be a bug.

I think there is also a solution to this problem. We can add an additional parameter to the Read constructor. A boolean that indicates whether there is a thread waiting for write access. If this boolean is set to False other threads can concurrently gain read access. If a thread tries to acquire write access while the lock is in the Read state the boolean will be set to True. Subsequent threads that attempt to get read access will be blocked.

basvandijk commented 10 years ago

I agree we should get rid of the race conditions in acqRead and acqWrite. The easiest solution would probably be to rewrite the ReadWriteLock in terms of STM. @roelvandijk want to give it a try?

basvandijk commented 10 years ago

The easiest solution would probably be to rewrite the ReadWriteLock in terms of STM.

Scratch that, AFAIK STM doesn't provide fairness guarantees. Only MVars do.