[dmd-concurrency] What is protected by synchronization?

[Robert Jacques]

On Sat, 30 Jan 2010 18:25:33 -0500, Michel Fortin  
<michel.fortin at michelf.com> wrote:
> Le 2010-01-30 à 17:25, Robert Jacques a écrit :
>
>> On Sat, 30 Jan 2010 15:30:04 -0500, Michel Fortin  
>> <michel.fortin at michelf.com> wrote:
>>
>>> Robert's comment in the other thread makes me realize I've skipped  
>>> over something important in my previous message: fields inside a  
>>> synchronized object shouldn't 'shared'. Despite being usable from many  
>>> threads due to synchronization, they behave much more like  
>>> thread-local fields where the thread they belong to changes depending  
>>> on who holds the lock.
>>
>> I assume this is only for value types and not references.
>
> This applies to both value types and reference types. The idea is that  
> they aren't 'shared', but they are also not accessible at all outside of  
> a synchronized block... More below.
>
>
>>> The only thing lacking is a way to avoid them from escaping when  
>>> passing them to functions. If we deem it necessary, we could add a  
>>> type modifier for that (although it probably won't enough by itself).
>>
>> The type modifier you are looking for is called 'owned'. Bartosz went  
>> into some detail of it on his blog. From a runtime perspective, owned  
>> objects are all protected by a common mutex, and are therefore shared  
>> objects. From a compile time perspective, it provides the ability to  
>> optimize away some recursive locks, etc.
>
> There are multiple ways to ensure correctness at this level. Either you  
> propagate the owner with the type of the variable, as Bartosz proposed,  
> or you propagate assignment constrains as I suggested even before that  
> when talking about 'scope' with Andrei on the forum.
>
> But...
>
> The thing is that I'm trying to make a best effort to have something  
> with reasonable performance and simplicity without introducing a type  
> modifier. Andrei and Walter aren't too keen on adding a type modifier,  
> so I think it's a good idea to push a concept without one as far as  
> possible.
>
> I'm perfectly aware that without adding proper support in the type  
> system there will always be loopholes. I think having these loopholes is  
> a more acceptable solution than forcing all referenced data to be shared  
> and use atomic operations (as Andrei suggested some time ago).
>
> For instance, if your class provides a synchronized interface to a tree  
> data structure, you need synchronized to affect the whole tree. Using  
> atomic operations everywhere in the tree is not going to be acceptable.  
> Not only it'll give you poor performance, but it also doesn't add any  
> safety: if somehow a pointer escapes and someone gains access to some  
> part of the tree without holding the lock, you'll get a race in the  
> program's logic because the algorithm manipulating the tree under the  
> lock doesn't expect that.
>
> So either the type system enforce that some variables are accessed only  
> through their lock, or it lets the programmer in charge of doing that.

I understand your concerns and share them. It's why I've supported and  
proposed different ownership type systems that address these issues. The  
problem is that your proposal is effectively re-creating either a lent or  
owned type poorly. At this point, since we are not going to get ownership  
types, I'd much rather have something safe and allow the gurus to cast  
stuff away as needed then to have a situation where there are loop-holes  
you could drive a Mac truck through. Honestly, I've read enough horror  
stories of threading gurus getting it wrong and of software killing people  
to prefer being safe to being sorry.

On that note, although I heard there were problems with owned/lent/unique,  
I never heard exactly what they were. Does anyone know what the particular  
issues were?