On 5/31/12 3:27 AM, Regan Heath wrote:
I think the mutex is "available for locking and unlocking" <- need a word for that, which is not "exposed". How about accessible, available, usable, or just plain lockable .. So, the problem here is that the mutex is lockable by external code via synchronized() and this means a certain type of deadlock is possible.
But this is a protection/visibility issue, which is orthogonal on the locking capability. It's as if you say "int is not good because anyone can overflow it." Okay! Make it private inside a CheckedInt class.
Moving on.. I think the change mentioned in TDPL to restrict synchronized to synchronized classes is a step in the right direction WRT wasted monitor space and people freely locking anything. But, it is exactly the case which results in more possible deadlocks (the cause of this thread) AND I think it's actually far more likely people will want to use a synchronized statement on a class which is not itself synchronized, like for example an existing container class. Given that, restricting synchronized statements to synchronized classes seems entirely wrong to me.
So where's the mutex that would be used to synchronize objects that are not synchronizable?
In fact, I would say you almost want to stop people using synchronized statements on synchronized classes because: 1. If a synchronized class is written correctly it should not be necessary in the general case(*) 2. It raises the chances of deadlocks (the cause of this thread). 3. It means that classes in general will be simpler to write (no need to worry about synchronization) and also more lightweight for use in non-threaded/non-shared cases. (because we'd provide a template wrapper to make them synchronizable)
There are cases in which you want to do multiple operations under a single critical section, even though the API is otherwise well-designed. That may be for correctness, efficiency, or both. I don't see why we'd want to disallow that, it's a good idiom.
So, more and more I'm thinking it would be better to provide a library/runtime co-operative solution where we have an interface which is required for synchronized statements, and a wrapper template to implement that interface for any existing non-synchronized class. Meaning, the choice is either to write a synchronized class (rare) or a non-synchronized class - knowing it can easily be synchronized if/when needed.
Looking forward for a fleshed out proposal. Make sure you motivate it properly.
The "liquid lock" problem mentioned earlier is an interesting one that I have not personally experienced, perhaps because I don't lock anything but mutex primitives and I never to re-assign these. (*) Locking on a larger scope can be achieved by providing a method taking a delegate (see earlier thread/replies) and/or exposing lock/unlock for those few situations where the delegate method cannot be used. These are the few cases in which this cannot be avoided as the lock/unlock are separated by more than a single scope (so synchronized statements don't help in these cases either).
On first look, the inversion of control using delegates delegates has similar liabilities as straight scoped locking.
Andrei
