On Jul 12, 2004, at 4:51 PM, Peter Dimov wrote:
That was the intent. But I stand corrected. I evidently got it wrong except on Mac OS X where I do explicitly decrement the count to 0 of the pthread_mutex during a wait (recursive mutex case only). Looks like I need to dig back into this on other platforms...
Doesn't this impose some overhead on your recursive_mutex, even if the user never takes advantage of this feature? (I have to admit that I don't have the slightest idea how is this possible to implement correctly.)
I'm not familiar with how a native pthread_mutex is made recursive. But with a native non-recursive mutex, the added space overhead simply to handle recursive locking was also sufficient to negotiate use with condition variables without further space overhead needed just for the condition variables. To support the condition variables, a little more code is needed (maybe a dozen lines of C++) executed from within the wait function, and maybe a dozen or so bytes of stack space within the condition's wait function. Essentially the wait function saves the state of the mutex before the wait, then frees it for the wait, then restores the state of the mutex after the wait. With a non-recursive mutex you do the same thing, except that the state of the mutex is so much simpler: it is locked before and after the wait, and unlocked during. So there is no need to store mutex "state" on the stack for a non-recursive mutex. -Howard