pthread_mutex_trylock does not lock

Christophe Galerne christophegalerne@earthlink.net
Wed Dec 4 15:53:00 GMT 2002


Robert Collins wrote:
> On Thu, 2002-12-05 at 08:33, Christophe Galerne wrote:
> 
> NB: PT_MUTEX_NORMAL is not a posix mutex type - it's PTHREAD_MUTEX_NORMAL.... 

Right that was a typo.

> Or you could check the return value from pthread_mutexattr_settype and
> see that it returns EINVAL.

The thing is it's not really an invalid value for 'type' in the call.
Maybe it would be better to break the compilation of programs that
expect this value rather than have the developpers debug their applications
before figuring it out.

Come to think about it, I'm wondering if there was a policy of having the 
headers right first then the implementation or if headers and imlpementation
came together. But that's maybe not the right maillist for that. =:-D

>>Also above
>>pthread.h(57): #define PTHREAD_MUTEX_INITIALIZER (void *)20
>>a comment that says that a default MUTEX will be recursive
>>might avoid some surprise. =:-D
> 
> Look at pthread.h:53 and pthread.h:58. DEFAULT is mapped to RECURSIVE 

That's a good point.
Onather solution that might be considered more elegant would be to
rearrange the defines to make the default behavior self-explanatory.
Ex.
#define PTHREAD_MUTEX_RECURSIVE 0
#define PTHREAD_MUTEX_ERRORCHECK 1
#define PTHREAD_MUTEX_NORMAL 2
#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_RECURSIVE

Christophe


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list