D const enables multi-reader synchronization

[Robert Jacques]

On Mon, 14 Jun 2010 15:17:57 -0400, Tomek Sowiński <just at ask.me> wrote:
> This is a continuation of a recent thread "Synchronized const methods"  
> on D.learn.
>
> Currently only one thread at a time can execute a synchronized method.  
> But think about D's const -- it's deep, so if a method is const, it  
> can't possibly mutate its object. So many synchronized const method  
> calls could safely look-but-not-touch the same object at the same time.
>
> The chain of questions that stems from the above is:
> 1. Is letting many readers in on an object really safe? Know any  
> multi-threading quirk that would make sh*t hit the fan?
> 2. If answer to 1. is yes, would there be room in the current  
> implementation of synchronized keyword for a readers-writer lock?
> 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.
>
> More on readers-writer lock:
> http://en.wikipedia.org/wiki/Readers-writer_lock
>
>
> Tomek

This has been suggested before and has been rejected. The major issue is  
that CREW (concurrent-read exclusive-write) locks are known to be not  
composite and therefore its trivial to write code which results in a  
deterministic dead-lock. The problem lies in that the const method can  
have access to a non-const reference to its object via method arguments  
and/or globals. Thus, a read-lock can be obtained first and then later a  
write lock is attempted. Since the first read lock will never be released,  
the write lock can never be taken and a deadlock occurs.