red floyd <no.s...@here.dude> writes: >Does POSIX define what happens when a pthread currently holding a mutex >locks the same mutex? >i.e. >void f() >{ > pthread_mutex_lock(&some_mutex); > pthread_mutex_lock(&some_mutex); >} >The Linux (MDK9.1) implementation of pthreads has a non-portable mutex >attribute letting you specify what behavior you want in said situation. >I'd like to try to write portable code, though.
Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
OK, thanks Joe and Casper. I guess my systems implementation is older, and thus the recursive mutex hadn't yet been standardized or something. So I'll simply #define something like this
1) You don't know the mutex is being used recursively. In this case, the recursive mutex will hide a serious problem.
2) You know the mutex is being recursively. In this case, just don't lock it since you know it's already locked anyway.
The problem is that recursive mutexes hide something from you and that something is extremely important. Consider code like this:
A) Lock mutex B) Unlock mutex C) Do something, assuming the mutex is unlocked
What happens if the mutex is recursive?
The only value of a recursive mutex is that it allows you to write a function that works properly whether or not a mutex is locked. But the caller must know that the mutex is locked anyway, so why not just have two versions of the function? (With the one you call without a lock possibly just being a wrapper that grabs the lock and calls the other function.)
It's just too hard and dangerous to write sensible code that works with a mutex that might or might not start out with that mutex locked and with no way to tell which. And the only value of recursive mutexes is that they let you do this.
> It's just too hard and dangerous to write sensible code that works with > a mutex that might or might not start out with that mutex locked and with no > way to tell which. And the only value of recursive mutexes is that they let > you do this.
SenderX wrote: >> It's just too hard and dangerous to write sensible code that >> works with a mutex that might or might not start out with that mutex >> locked and with no way to tell which. And the only value of >> recursive mutexes is that they let you do this. > There good for hashed locks.
I can't imagine how. The only way they might help is if you have code that grabs more than one object and they might 'happen to' have the same lock protecting them. But if your code does this, they might also happen to have different locks protecting them. In this case, you must enforce your lock ordering rules or else you can deadlock.
In other words, if one thread can grab object A then object B, grabbing lock 1 followed by lock 2, another thread could grab object C followed by object D, grabbing lock 2 followed by lock 1. Then you deadlock.
So if you're going to use hashed locks, you may either hold two locks at once or you may not. If you may not, recursive locks don't help.
If you may, then you must check to see what locks they refer to so that you acquire them in the right order. While you're doing this, it's just as easy to check if they're the same lock, and if so only acquire it once. So recursive locks don't help you in this case.
Worse, recursive locks might lull you into thinking you don't have to check what locks you are acquiring, and then you are vulnerable to lock order reversal and deadlocks.
red floyd wrote: > Alexander Terekhov wrote: >> red floyd wrote: ...
>> Don't use recursive mutexes. It's akin to sex with used condoms. ;-)
>> regards, >> alexander.
> May I ask why?
Other than Mr. Schwartz reply (which I consider absolutely good), I may add also that recursive mutexes are slower (they must check if they are locked or not) and brings you to program less carefully about shared resource usage. If you stop to think twice about that, you'll realize that when you want to lock a resource, you just want to know that you are the owner of that, and not that you've been entitled to be the owner N times...
The only reason I can see for recursive mutexes is to call recursive functions, where the locks are so complex that writing a wrapper is not a viable way, or to create "onion peel" like libraries where the lower levels are completely obscure and abstracted to the higher ones, and there is sometimes the need to "extend" the mutex locking also to some function in the higher levels; but in both the cases there are probably better ways to deal with the problem with a non recursive mutex, with a little more cleaner design effort.
> It's just too hard and dangerous to write sensible code that works with > a mutex that might or might not start out with that mutex locked and with no > way to tell which. And the only value of recursive mutexes is that they let > you do this.
Uhh.. OK I have a class protected by an internal mutex. I wish to derive from the class & add some extra private data & methods in my descendant. I want the private data in the child to be protected by the mutex, so I obtain it in the child. The methods in the child call the inherited methods of the parent, which attempt to get the mutex.again & deadlock the single caller.
Now what? I can add protected 'unlocked' methods in the parent class that are called from public methods in the parent that get the mutex first. The child must then ensure that it only calls the unlocked methods that don't get the mutex. Is this messy & dangerous compared with recursive mutexes or what?
Martin James wrote: >> It's just too hard and dangerous to write sensible code that >> works with a mutex that might or might not start out with that mutex >> locked and with no way to tell which. And the only value of >> recursive mutexes is that they let you do this. > Uhh.. OK I have a class protected by an internal mutex. I wish to > derive from the class & add some extra private data & methods in my > descendant. I want the private data in the child to be protected by > the mutex, so I obtain it in the child. The methods in the child > call the inherited methods of the parent, which attempt to get the > mutex.again & deadlock the single caller.
Right, that would be bad.
> Now what? I can add protected 'unlocked' methods in the parent > class that are called from public methods in the parent that get the > mutex first. The child must then ensure that it only calls the > unlocked methods that don't get the mutex. Is this messy & dangerous > compared with recursive mutexes or what?
No, it's cleaner and safer by *far*. What happens when someone adds some code to the class that looks like this:
LockMutex(); while (ObjectIsNotReady()) { UnlockMutex(); BlockOnEvent(); LockMutex();
}
DoStuff(); UnlockMutex();
Now, all of a sudden, that 'UnlockMutex()' is a nop, and the loop will spin forever. The problem is that the functions in the inner class can *only* look exactly like this:
LockMutex(); DoStuff(); UnlockMutex();
Otherwise, the functionality in derived classes may change what code is run holding the mutex and what code is run without it, and that's very, very scary.
> Now, all of a sudden, that 'UnlockMutex()' is a nop, and the loop will > spin forever.
I guess it's a moot point whether a deadlock or livelock is spotted first :)
The problem is that the functions in the inner class can
> *only* look exactly like this:
> LockMutex(); > DoStuff(); > UnlockMutex();
Anther moot point is whether the chances of a developer adding dubious code that attmpts to unlock a mutex inside an encapsulated object is any greater or less than a developer accidentally calling the locking, rather than the lockfree, method of a parent.
> Otherwise, the functionality in derived classes may change what code is > run holding the mutex and what code is run without it, and that's very, very > scary.
Once acquired, always acquired, that's what I say :)
I have to agree that code can be written to screw up almost anything. I'm quite happy to put up with the onerous restriction of:
> LockMutex(); > DoStuff(); > UnlockMutex();
in order to avoid the complications of locking and unlocking methods in the same class.
> > No, I will not use two mutexes :)
> That may or may not make more sense.
No thanks. Four classes down, I'm acquiring four mutexes & some developer will find a way of acquiring them out-of-order.
Martin James wrote: > No thanks. Four classes down, I'm acquiring four mutexes & some > developer will find a way of acquiring them out-of-order.
Recursive mutexes make the risk of this *much* greater and *much* harder to detect. What happens when some member of your class hierarchy calls another function that needs to acquire a mutex?
> 1) You don't know the mutex is being used recursively. In this case, the > recursive mutex will hide a serious problem.
> 2) You know the mutex is being recursively. In this case, just don't > lock it since you know it's already locked anyway.
> The problem is that recursive mutexes hide something from you and that > something is extremely important. Consider code like this:
> A) Lock mutex > B) Unlock mutex > C) Do something, assuming the mutex is unlocked
> What happens if the mutex is recursive?
Recursive locks work only for the same (current) thread. The code above is IMO wrong, obviously it should be: A) Lock mutex B) Do something C) Unlock mutex
and this is ok too (here the recursive feature is in action): A) Lock mutex B) Do something C) Lock mutex D) Do something2 E) Unlock mutex F) Unlock mutex
C and E are redundant, however application code (the current thread) cannot always know that it alread has the lock, though it could test for it. But testing is unnessary because calling such a Lock() will already do the testing implicitly, so then there is no need for an explicit testing in applic code, it just would make code longer and slow down the performance.
To clarify: there is Lock() without recursive feature, and there is Lock() with recursive feature. And: such lock objects are initialized at creation.
> The only value of a recursive mutex is that it allows you to write a > function that works properly whether or not a mutex is locked. But the > caller must know that the mutex is locked anyway, so why not just have two
usually the calling thread must not know that; it simply can issue a Lock() request of its own. If it is already locked by this thread then recursion is in effect and the lock will be granted very fast.
> versions of the function? (With the one you call without a lock possibly > just being a wrapper that grabs the lock and calls the other function.)
> It's just too hard and dangerous to write sensible code that works with > a mutex that might or might not start out with that mutex locked and with no > way to tell which. And the only value of recursive mutexes is that they let > you do this.
Lock objects are initialized at creation, they don't have a random state. Recursive locks are very practical. It saves coding and prevents from self-deadlocking.
> C and E are redundant, however application code (the current thread) > cannot always know that it alread has the lock, though it could test for > it.
Yes, it can and must know that it already has the lock. A function that operates on X should be defined as being called with X locked, or with X unlocked. It could even take a boolean that indicates whether the caller has locked the object or not, though this is rarely the right thing to do.
Simply put, the only thing recursive mutexes gives you is the ability to write code that deals with X that can be called whether or not X is locked. This is not only almost never useful, but it's almost always dangerous.
"Uenal Mutlu" <520001085531-0...@t-online.de> writes: > "David Schwartz" wrote >> red floyd wrote:
>> > May I ask why?
>> There are two possibilities:
>> 1) You don't know the mutex is being used recursively. In this case, the >> recursive mutex will hide a serious problem.
>> 2) You know the mutex is being recursively. In this case, just don't >> lock it since you know it's already locked anyway.
>> The problem is that recursive mutexes hide something from you and that >> something is extremely important. Consider code like this:
>> A) Lock mutex >> B) Unlock mutex >> C) Do something, assuming the mutex is unlocked
>> What happens if the mutex is recursive?
> Recursive locks work only for the same (current) thread.
I sure hope so.
> The code above is IMO wrong, obviously it should be: > A) Lock mutex > B) Do something > C) Unlock mutex
David meant what he said. What if the something is signaling another thread to go ahead with something that locks the mutex, and then wait for that other thread to signal you back? Deadlock.
> and this is ok too (here the recursive feature is in action): > A) Lock mutex > B) Do something > C) Lock mutex > D) Do something2 > E) Unlock mutex > F) Unlock mutex
> C and E are redundant, however application code (the current thread) > cannot always know that it alread has the lock, though it could test > for it.
Bad application design. A properly designed application will always know what to expect.
>> It's just too hard and dangerous to write sensible code that >> works with a mutex that might or might not start out with that >> mutex locked and with no way to tell which. And the only value of >> recursive mutexes is that they let you do this.
> Lock objects are initialized at creation, they don't have a random > state. Recursive locks are very practical. It saves coding and > prevents from self-deadlocking.
In all the years I've been programming, I have never used a recursive mutex (except in Java, but that's another story).
> > C and E are redundant, however application code (the current thread) > > cannot always know that it alread has the lock, though it could test for > > it.
> Yes, it can and must know that it already has the lock. A function that > operates on X should be defined as being called with X locked, or with X > unlocked. It could even take a boolean that indicates whether the caller has > locked the object or not, though this is rarely the right thing to do.
You are unnecessarily complicating things and make the program slower by doing these testings. These tests are not necessary if your design is good.
> Simply put, the only thing recursive mutexes gives you is the ability to > write code that deals with X that can be called whether or not X is locked.
Not true. It is the caller's job to call X only after having the lock. It is not X's job to check whether the object was locked. Do you see the difference, and the consequence, and what it means for performance?
> This is not only almost never useful, but it's almost always dangerous.
Recursive locking has less dangers than locking without recursive feature. Proof: using recursive locking you never can block or deadlock yourself, but using a locking method without recursive feature you can very easily deadlock yourself. In the latter case even just blocking (ie. waiting for the lock) means deadlock! Don't you see that?
> >> 1) You don't know the mutex is being used recursively. In this case, the > >> recursive mutex will hide a serious problem.
> >> 2) You know the mutex is being recursively. In this case, just don't > >> lock it since you know it's already locked anyway.
> >> The problem is that recursive mutexes hide something from you and that > >> something is extremely important. Consider code like this:
> >> A) Lock mutex > >> B) Unlock mutex > >> C) Do something, assuming the mutex is unlocked
> >> What happens if the mutex is recursive?
> > Recursive locks work only for the same (current) thread.
> I sure hope so.
> > The code above is IMO wrong, obviously it should be: > > A) Lock mutex > > B) Do something > > C) Unlock mutex
> David meant what he said. What if the something is signaling another > thread to go ahead with something that locks the mutex, and then wait > for that other thread to signal you back? Deadlock.
This has nothing to do with recursive locking per se, does it? I mean: the same would happen also without recursive locking, wouldn't it? And, apart from that I don't think this way. In my thinking each thread knows itself only and tries to lock the shared object(s) before changing its/their content. We are talking of locking some shared objects here, don't we? You maybe should give a practical example in pseudocode for what you mean.
> > and this is ok too (here the recursive feature is in action): > > A) Lock mutex > > B) Do something > > C) Lock mutex > > D) Do something2 > > E) Unlock mutex > > F) Unlock mutex
> > C and E are redundant, however application code (the current thread) > > cannot always know that it alread has the lock, though it could test > > for it.
> Bad application design. A properly designed application will always > know what to expect.
This is a shortsighted view. What do you think recursive locking is intended for? Recursive locking has nearly no overhead if the implementation of lock() and unlock() were properly done. They have many many advantages.
> >> It's just too hard and dangerous to write sensible code that > >> works with a mutex that might or might not start out with that > >> mutex locked and with no way to tell which. And the only value of > >> recursive mutexes is that they let you do this.
> > Lock objects are initialized at creation, they don't have a random > > state. Recursive locks are very practical. It saves coding and > > prevents from self-deadlocking.
> In all the years I've been programming, I have never used a recursive > mutex (except in Java, but that's another story).
Uenal Mutlu wrote: > "David Schwartz" wrote >> Yes, it can and must know that it already has the lock. A >> function that operates on X should be defined as being called with X >> locked, or with X unlocked. It could even take a boolean that >> indicates whether the caller has locked the object or not, though >> this is rarely the right thing to do.
> You are unnecessarily complicating things and make the program > slower by doing these testings.
> >> >> The problem is that recursive mutexes hide something from > >> >> you and that something is extremely important. Consider code > >> >> like this:
> >> >> A) Lock mutex > >> >> B) Unlock mutex > >> >> C) Do something, assuming the mutex is unlocked
> >> >> What happens if the mutex is recursive?
> >> > Recursive locks work only for the same (current) thread.
> >> I sure hope so.
> >> > The code above is IMO wrong, obviously it should be: > >> > A) Lock mutex > >> > B) Do something > >> > C) Unlock mutex
> >> David meant what he said. What if the something is signaling another > >> thread to go ahead with something that locks the mutex, and then wait > >> for that other thread to signal you back? Deadlock.
> > This has nothing to do with recursive locking per se, does it? I > > mean: the same would happen also without recursive locking, wouldn't > > it?
> No, because having unlocked the mutex, you can be certain that the > other thread will be able to acquire it. If the mutex is recursive, > you can't know which level you just unlocked.
You are expecting a specific thread will get the released lock? This can't work.
> > And, apart from that I don't think this way. In my thinking each > > thread knows itself only and tries to lock the shared object(s) > > before changing its/their content. We are talking of locking some > > shared objects here, don't we?
> If "each thread knows itself only", how can we be talking about shared > objects at all?
Because we are talking of threads and not processes...
> > You maybe should give a practical example in pseudocode for what you > > mean.
> >> > and this is ok too (here the recursive feature is in action): > >> > A) Lock mutex > >> > B) Do something > >> > C) Lock mutex > >> > D) Do something2 > >> > E) Unlock mutex > >> > F) Unlock mutex
> >> > C and E are redundant, however application code (the current thread) > >> > cannot always know that it alread has the lock, though it could test > >> > for it.
> >> Bad application design. A properly designed application will always > >> know what to expect.
> > This is a shortsighted view. What do you think recursive locking is > > intended for?
> They are for lazy programmers unwilling to learn proper design.
I would say this applies exactly to yourself.
> > Recursive locking has nearly no overhead if the implementation of lock() > > and unlock() were properly done.
> I'm not worried about overhead. I'm worried about writing buggy code.
Then continue worrying. Using recursive locking is safer than using one which doesn't have such recursive feature.
> > They have many many advantages.
> Prove it. Show me one problem that can't be solved better without them.
Since you don't believe me it's your turn to prove that recursive locking is more dangerous (your saying) than using no recursive locking. My point is: recursive locking is much safer than non-recursive locking.
> >> >> It's just too hard and dangerous to write sensible code that > >> >> works with a mutex that might or might not start out with that > >> >> mutex locked and with no way to tell which. And the only value of > >> >> recursive mutexes is that they let you do this.
> >> > Lock objects are initialized at creation, they don't have a random > >> > state. Recursive locks are very practical. It saves coding and > >> > prevents from self-deadlocking.
> >> In all the years I've been programming, I have never used a recursive > >> mutex (except in Java, but that's another story).
> > Then you must have overlooked their real value.
> Or I realized their real danger.
I doubt it because there is no danger in using recursive locking over non-recursive locking. OTOH recursive locking has advantages over non-recursive locking. So what? If you doubt this then prove it.
(Follow-up set to comp.programming.threads where it belongs to)
> Uenal Mutlu wrote: > > "David Schwartz" wrote > >> Yes, it can and must know that it already has the lock. A > >> function that operates on X should be defined as being called with X > >> locked, or with X unlocked. It could even take a boolean that > >> indicates whether the caller has locked the object or not, though > >> this is rarely the right thing to do.
> > You are unnecessarily complicating things and make the program > > slower by doing these testings.
> No, he's in fact making the program faster.
Are you sure? Let's see:
void X::f() { Lock(); for (int i = 0; i < 1000; i++) f(); Unlock();
}
void X::g() { if (!IsLocked()) return; //...do..something...
}
Are you saying the above version of g() is faster than this one: ? void X::g() { //...do..something...
Uenal Mutlu wrote: > "Peter Dimov" wrote >> Uenal Mutlu wrote: >>> "David Schwartz" wrote >>>> Yes, it can and must know that it already has the lock. A >>>> function that operates on X should be defined as being called with >>>> X locked, or with X unlocked. It could even take a boolean that >>>> indicates whether the caller has locked the object or not, though >>>> this is rarely the right thing to do.
>>> You are unnecessarily complicating things and make the program >>> slower by doing these testings.
>> No, he's in fact making the program faster.
> Are you sure? Let's see:
> void X::f() > { > Lock(); > for (int i = 0; i < 1000; i++) > f();
Stack overflow or deadlock here, you probably wanted to call g().
