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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1307181059460.22570>