[boost] Re: Boost.Threads: Do we need all those mutexes?

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.