Thin Lock Implementation

[Sean Kelly]

== Quote from Bartosz Milewski (bartosz at relisoft.com)'s article
> Sean Kelly wrote:
> > The benefit of being able to cast away the shared label is clearly for
> > performance... if you know that you're the sole owner of a shared object
> > then you don't need to lock for otherwise synchronized accesses (so
> > long), much like assertUnique for const/invariant data.
> There is one complication though--the type system. A function that takes
> a non-shared argument can't be called with a shared object. But it's
> true that a sharing cast is an optimization. The safe way to do it is to
> make a thread-local deep copy of the object and pass that to a library
> function. (Object cloning is a hot topic in D.)

Yeah, that's the nasty thing about atomics--they provide yet another reason
to duplicate function bodies.  Sometimes I wonder if we won't eventually end
up writing only template code simply out of necessity.

I've had the same thought about cloning, though.  Once 'shared' is in place
we'll need to perform deep copies to transfer local data between threads,
and I would expect such passing to be far more common than the use of
shared data.  So we'll need a reliable and efficient means of cloning.  But
then we'll need the same thing for STM, so I guess we'll be killing two
birds with one stone :-)


Sean