Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Jul 2013 11:09:04 -0400 (EDT)
From:      Daniel Eischen <deischen@freebsd.org>
To:        Joe Marcus Clarke <marcus@marcuscom.com>
Cc:        Koop Mast <kwm@rainbow-runner.nl>, freebsd-threads@freebsd.org
Subject:   Re: Mutexes and error checking
Message-ID:  <Pine.GSO.4.64.1307181059460.22570@sea.ntplx.net>
In-Reply-To: <51E71D4F.5030502@marcuscom.com>
References:  <51E71D4F.5030502@marcuscom.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Wed, 17 Jul 2013, Joe Marcus Clarke wrote:

> It seems we might have a discrepancy between the way our pthread
> implementation works compared to Linux.  If a mutex is set to NORMAL
> type and one goes to unlock it, EPERM is returned unless the current
> thread is the mutex owner.  While this sounds perfectly sane, it appears
> Linux only returns EPERM if the mutex type is ERRORCHECK.
>
> We are seeing some problems in ported code because of this.  As a
> suggestion, if people agree, would it be possible to emulate the
> behavior of Linux and only return EPERM if the mutex is of type
> ERRORCHECK or RECURSVIE?

First, any software that does that is broken.

Second, the POSIX spec seems to imply that an error is returned
when a different thread tries to unlock an already locked mutex:

   http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.htm

Is the mutex robust or not robust?  If not robust
(PTHREAD_MUTEX_STALLED), then a PTHREAD_MUTEX_NORMAL mutex
cannot be unlocked by any other thread than the owner.
So, it would seem to be wrong to _not_ return an
error when the mutex is not unlocked after
pthread_mutex_unlock() returns.

-- 
DE



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1307181059460.22570>