Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2004-07-14 05:27:44


Howard Hinnant wrote:

[... cv.wait with recursively locked mutex ...]

> This is the big question in my mind right now. I know how to make it
> work with a home-grown recursive mutex. But I don't know how to make
> it work with a native recursive mutex, combined with a native
> condition. I'm somewhat surprised that it doesn't just work.

It does just work. As long as you call cv.wait with a recursive mutex
locked by the calling threads and its "lock count == 1". Calling it
with "lock count != 1" is a bug (violation of a precondition in C++
terms).

> Alexander, can we send a bug report to the pthreads guys?

http://www.opengroup.org/austin/defectform.html

> Or would we
> just be laughed out of the room? I'm not educated enough to know what
> the problems are to making it work.

It is a philosophical issue, not technical. I wouldn't oppose if you
would propose to add

   int pthread_mutex_setlockcount(
     // must be locked by the calling thread
     pthread_mutex_t * mutex,
     // must be positive (> 1 can be set on PTHREAD_MUTEX_RECURSIVE only)
     unsigned lockcount,
     // can be null
     unsigned * oldlockcount
   );

(or something like that, "get" aside for a moment)

so that you could do
  
  [...]
  while (!predicate) {
    unsigned lockcount;
    pthread_mutex_setlockcount(&mutex, 1, &lockcount);
    pthread_cond_wait(&condvar, &mutex);
    pthread_mutex_setlockcount(&mutex, lockcount, 0);
  }
  [...]

if/when you're ablsolutely 100% sure that what you're doing is OK.

> And clearly it doesn't work today,
> so it's a problem whether or not it can be fixed. <sigh> That
> probably backs us into undefined behavior if the mutex is recursively
> locked,

Exactly. "may fail error" (in POSIX terms; optional "throws" that
end up in std::unexpected with no return from the "failed" call).

http://groups.google.com/groups?selm=3434E6BA.ABD%40zko.dec.com

----
The one omission in XSH5 recursive mutex support was a standard error
code for the programming ERROR of trying to wait on a condition with a
recursively locked mutex. If it's safe to release the recursive locks,
the code should have done so. If it's not safe to release, then the
runtime MUST NOT do so.
----
>         or refusing to compile at all with a recursive mutex.  
No, that's not good. 
regards,
alexander.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk