[dmd-concurrency] What is protected by synchronization?

[Michel Fortin]

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.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/