Le 31/05/2012 11:55, Regan Heath a écrit :
On Thu, 31 May 2012 10:48:51 +0100, 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.
Depends on your definition of "free". You appear to have meant as an
instance/pointer/object even one in a class, I initially read it as
meaning as a separate object from the class you're locking. In any case,
you're right the compiler doesn't get synchronized()
statements/classes/methods wrong and a programmer can. The trade-off is
the cause of this thread of discussion.
R
I think you misunderstand each other. Here is what I nderstand :
Andrei is talking about free mutex in the sense of a mutex with lock and
unlock function available. Such a mutex is error prone, because you can
lock/unlock in an incorrect way.
synchronized is here a better alternative, because lock and unlock
always goes by pair.
Regan, by free mutex, you mean a mutex that can be locked and unlocked
by everybody. This is problematic too.
The ideal is to lock in a way that isn't a free mutex in both definition
of the term.
