D const enables multi-reader synchronization

Sean Kelly sean at invisibleduck.org
Thu Jun 17 07:37:25 PDT 2010


Tomek Sowiński <just at ask.me> wrote:
> Sean Kelly wrote:
> 
>> Tomek Sowi�ski 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.
>> 
>> It's an interesting idea but I'd recommend against it for a few
> > reasons:
>> 
>> 1. Acquiring, using, and releasing a reader lock is actually more
>> expensive than a plain old mutex so it isn't a good idea to use one
> > just
>> because you can.  A ReadWriteMutex is really for addressing convoying
>> problems on containers.
>> 
>> 2. The typical implementation of a ReadWriteMutex doesn't permit
> > recursive
>> up/downgrades from reader to writer and such.  It's technically
> > possible
>> to do this, but doing so requires a lot more machinery and
> > consequently
>> trades away even more performance.
> 
> That shed some light, thanks.
>  
>> That said, if you're inclined to experiment there's a ReadWriteMutex
> > in
>> core.sync.rwmutex (which you already may know).
> 
> I didn't know it even existed:) The library reference seems a bit
> broken. 
> Some core modules are camouflaged as std.* (e.g. std.thread, std.gc is
> 
> core.memory for some reason), core.sync is not even listed.
> 
> http://www.digitalmars.com/d/2.0/phobos/phobos.html

The Phobos wrappers exist for backwards compatibility, I suppose it's
high time they were removed. I really need to see about bundling the
druntime docs with the Phobos docs.


More information about the Digitalmars-d mailing list