Something needs to happen with shared, and soon.

[Dmitry Olshansky]

11/15/2012 8:33 AM, Michel Fortin пишет:

> If you want to declare the mutex separately, you could do it by
> specifying a variable instead of a type in the variable declaration:
>
>      Mutex m;
>      synchronized(m) int i;
>
>      synchronized(i)
>      {
>          // implicit: m.lock();
>          // implicit: scope (exit) m.unlock();
>          i++;
>      }

While the rest of proposal was more or less fine. I don't get why we 
need escape control of mutex at all - in any case it just opens a 
possibility to shout yourself in the foot.

I'd say:
"Need direct access to mutex? - Go on with the manual way it's still 
right there (and scope(exit) for that matter)".

Another problem is that somebody clever can escape reference to unlocked 
'i' inside of synchronized to somewhere else.

But anyway we can make it in the library right about now.

synchronized T ---> Synchronized!T
synchronized(i){ ... } --->

i.access((x){
//will lock & cast away shared T inside of it
	...
});

I fail to see what it doesn't solve (aside of syntactic sugar).

The key point is that Synchronized!T is otherwise an opaque type.
We could pack a few other simple primitives like 'load', 'store' etc. 
All of them will go through lock-unlock.

Even escaping a reference can be solved by passing inside of 'access'
a proxy of T. It could even asserts that the lock is in indeed locked.

Same goes about Atomic!T. Though the set of primitives is quite limited 
depending on T.
(I thought that built-in shared(T) is already atomic though so no need 
to reinvent this wheel)

It's time we finally agree that 'shared' qualifier is an assembly 
language of multi-threading based on sharing. It just needs some safe 
patterns in the library.

That and clarifying explicitly what guarantees (aside from being well.. 
being shared) it provides w.r.t. memory model.

Until reaching this thread I was under impression that shared means:
- globally visible
- atomic operations for stuff that fits in one word
- sequentially consistent guarantee
- any other forms of access are disallowed except via casts

-- 
Dmitry Olshansky