[dmd-concurrency] CSP: Communicating sequential processes

[Michel Fortin]

Le 2010-01-20 à 2:53, Robert Jacques a écrit :

> Sort of; I was thinking about implicit use and not explicit use; i.e. const functions would take a reader lock and non-const function would take a writer lock. Generally, I've heard reports that CREW locks give big performance boosts in certain domains (game programming, for instance), but I don't know exactly the real performance trade-off compare to normal locks under low contention. Still, it would be nice to be able to replace an object's mutex with a rwmutex and have it work right.

I think read/write lock usage should only be used explicitly.

That's because you can never upgrade "safely" from a read lock to a write lock, or to be precise there is always a risk that you must release your read lock before upgrading. Two threads could acquire a read lock and then both might want to upgrade to a write lock, which can't be satisfied without one of them dropping its read lock first.

If the read lock drops because you call another function that wants a write lock, this could be trouble. Upgrades work well when there is only one thread requesting upgrades. Otherwise the upgrade must be seen as a drop-read-lock then acquire-write-lock non-atomic operation.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/