Thin Lock Implementation

[Steven Schveighoffer]

"Bartosz Milewski" wrote
> Steven Schveighoffer wrote:
>> Reading further messages in your blog, I see that you expect sharing 
>> casts to be recursive (to preserve the transitive nature of it).  What if 
>> two shared objects have references to the same shared object?  If you 
>> 'unshare' one parent, the other object now is shared, but its 
>> subcomponent is not shared.  Is that considered ok?
>
> No, it's definitely not ok, but unless there is a reference-counting 
> mechanism in place, we can't do anything about it during casting. However, 
> the sub-objects will be marked as exclusively owned by the casting thread, 
> so any attempt from another thread to lock them will result in an 
> exception. This is true to the spirit of casting in general.

Yes, it's similar to casting something to invariant when you are not sure 
that another reference doesn't exist.

However, in this case, the casting is considered to be an accepted practice 
(and probably more likely than casting something back and forth from 
invariant).  Normally, casting has big warning signs all over it, I see this 
as a commonly used feature (or should it be?).

I noticed that you have 'locked' and 'unshared' concepts as separate, the 
former using contention and the latter which is a try-only version.  Is 
there any enforcement for not using either of these?  For example, if thread 
A tries to access (without casting) a shared object when thread B has casted 
it to unshared, does it succeed?

The thing I'm trying to figure out in all this is, I can see the potential 
with the implementation you are coming up with for some really cool locking 
features, yet the 'shared/unshared' plan also has to do with lock-free 
programming (with fences and stuff, I'm not very familiar with these 
things).  It looks to me like you can do one or the other, but not both? 
How do you know which mode you are using a shared variable in?

-Steve