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
