Sharing in D

[Russell Lewis]

Steven Schveighoffer wrote:
> I think there may be no middle ground, as in order for locks to work, every 
> access to a locked variable must be through the lock.  If you have 2 
> references to a variable, one that is shared and one that is not, locking on 
> the shared variable does nothing to prevent the unshared variable from being 
> accessed without the lock.
> 
> I think the middle ground simply needs to do the most safe thing (i.e. treat 
> as shared), but not allow implicit casting to unshared or shared.
> 
> However, in this case, you incur a possible performance hit when it might 
> not be necessary.  It might be that the middle ground is simply undesirable, 
> so you have to do explicit casting.

I think that you misunderstood my locking idea.  My idea was that there 
was only one root reference to a variable, and you have to grab the lock 
to get to it.  So you can treat it as unshared while you hold the lock 
(with all the performance benefits, and code conveniences like ++, that 
you get with unshared data) but while you do not hold the lock it is 
absolutely inaccessible.

Put more explicitly, a "locked" variable has three modes:
    shared, in accessible to all
    locked in read mode, unshared const scope to one thread
    locked in write mode, unshared scope to one thread

Of course, you can't have external pointers pointing into the data 
structure (from outside the lock), but inside the lock it's perfectly OK 
to have pointers to other things inside the lock (or to external shared 
data).  So you could, for instance, build a doubly-linked list; you just 
make the sure that your global variable, which points to the head of the 
list, is declared as "locked".