> > [[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
> > >Thanks jrjnks for responding.
> > >The 4 sttribute types you mentioned are listed under
> > >pthread_mutexattr_settype() when I searched the web. But I could not
> > >find them in my Solaris 2.6. I suspect they are 2.7 additions.
> > >My 2.6 manual says pthread_mutex_unlock() returns EPERM if it is not
> > >the owner of the lock, which is exactly the bahavior I fail to see,
> > >forcing me to think this is a bug. But because Solaris is Solaris, I
> > >a bit hesitant about calling foul. Because I could have missed
> > >something.
> > Which manual page is that?
> > I can't find a reference to EPERM on a 2.6 system around here.
> Hi Casper:
> Thanks for pointing it out. I had made a mistake. I was working at a
> Solaris 2.6 machine while looking at an older Solaris 2.5 Answerbook.
> To my surprise 2.6 man pages do not specify an EPERM return value
> though they make comments like "only the thread that locked a mutex can
> unlock it" in man pthread_mutex_unlock.
> My guess is that 2.5 and 2.6 had a bug but rather than fixing it in
> 2.6, they just deleted the EPERM part from the RETURN part of the
> Let me also reply to Andrew since his post is somehow not showing up in
> the group ( I got an e-mail copy )
> Andrew>It's your responsibility, by default, to make sure that only the
> Andrew>thread that locks a mutex tries to unlock it. Otherwise the
> Andrew>behaviour is undefined.
> Not really POSIX ensures that implementation will let only the locked
> thread to unlock it. This is acknowledge by solaris as well in
> their "only the thread that locked a mutex can unlock it" phrase. I
> also read this in Kleiman et. al 's "Programming with threads".
No, you're misunderstanding POSIX. POSIX says that YOU, the application
developer, are not allowed to unlock a mutex you do not own. The
implementation IS ALLOWED TO (but need not) detect and report YOUR error by
Andrew Gierth was absolutely correct. The obligation is entirely on you. No
specific behavior is required of the implementation. Correct code does not
unlock the mutex from a thread that didn't lock it, and the effect of this
application error on the behavior of the process is not defined by POSIX.
This is why The Single UNIX Specification, Version 2 (aka UNIX 98) does not
specify the meaning of the "default mutex type" symbol. (This was actually
one of the few issues in the development of the specification where I was
wrong.) I argued that it would not be legal for an implementation to make
"recursive" the default mutex type, because the behavior is substantially
different in ways the application can detect. Eventually, though, I was
made to realize that the differences could be detected only by BROKEN
applications. Because the semantics of "default mutex" are not defined to
include the ability to re-lock a mutex from the owning thread, any
application that does this is wrong -- and no less wrong because the mutex
happens to be "recursive". The behavior of the erroneous application is
undefined, and there's nothing really worse about the behavior if the mutex
happens to be recursive. (An application designed for that particular
platform might "correctly", but not "portably", depend on the fact that the
default mutex is recursive -- but it'd be really bad design.)
The application is 100% responsible for correctness. The implementation may
help detect errors; but whether it does or not, it's the application that's
> Andrew>If you want mutex locking to be error-checked, you need to
> Andrew>create the mutex with the PTHREAD_MUTEX_ERRORCHECK type
> PTHREAD_MUTEX_ERRORCHECK is a type of teh mutex. Though I m not sure I
> suspect this was not there in the initial standard ( Both my books on
> pthreads do not make any mention of it ). Solaris did not have a
> pthread_mutexattr_settype() interface till 2.7 ( or 2.8 ??. It
> definitely wasn t there till 2.6 ). Instead this was the default
> behavior as per the man pages.
> Andrew>p.s. given that your code didn't contain any error checking, how
> Andrew>exactly were you expecting it not to work?
> see the above
You're arguing from a flawed assumption. You're deliberately doing
something wrong. You are of course justified in suggesting that the
implementation could have helped you to discover the application error --
but you also have to realize that the standard does not make any such
requirements. In terms of standards conformance, the implementation is not
at fault here, only your expectations.
Of course, "debug friendly" libraries are nice, and can help a lot during
development. However, it's complicated and difficult to maintain separate
production and debug libraries, and putting some times of error checking
(including this) into production thread libraries can be unreasonably and
And, in any case, the implementation could have "helped" only by returning
an error code, for which you're not checking. You would have ignored the
only help it could offer!
| Compaq Computer Corporation http://members.aol.com/drbutenhof |
| 110 Spit Brook Rd ZKO2-3/Q18, Nashua NH 03062-2698 |
\--------[ http://www.awl.com/cseng/titles/0-201-63392-2/ ]-------/