On Thu, 31 May 2012 11:39:06 -0400, Sean Kelly <s...@invisibleduck.org>
wrote:
On May 31, 2012, at 2:48 AM, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 5/31/12 2:36 AM, Regan Heath wrote:
On Wed, 30 May 2012 19:29:39 +0100, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
You can have deadlocks but with synchronized you can't leak locks or
doubly-unlock them. With free mutexes you have all of the above.
I'm not suggesting using free mutexes. I'm suggesting keeping the mutex
private inside the object.
Ergo, you are suggesting using free mutexes. Your second sentence
destroys the first.
To be fair:
auto m = new Mutex;
synchronized (m) {...}
Free mutexes but still safe. Scope guards obviously work too. That said,
I think the point of contention here is that because synchronized can
take an arbitrary object, it's possible to lock on a class for stuff
completely unrelated to what the class does internally. It's certainly
bad form though, and I don't know a good way to prevent it without
crippling synchronized.
See my suggestion and Dmitry's in other parts of this thread. The idea is
that you still allow synchronized(x), but only if the author of x allows
it.
If we use lowering, and make the lock and unlock methods of some entity,
then you can also use attributes to limit scope of synchronized.
For example, if we make synchronized(x) equivalent to calling x.lock() and
x.unlock() correctly, if lock() and unlock() are private, then you can
only call synchronized(x) from inside the instance.
-Steve
