Date: Thu, 18 Jul 2013 23:55:31 +0800 From: Julian Elischer <julian@freebsd.org> To: Daniel Eischen <deischen@freebsd.org> Cc: Joe Marcus Clarke <marcus@marcuscom.com>, Koop Mast <kwm@rainbow-runner.nl>, freebsd-threads@freebsd.org Subject: Re: Mutexes and error checking Message-ID: <51E80FF3.2080101@freebsd.org> In-Reply-To: <Pine.GSO.4.64.1307181118100.22570@sea.ntplx.net> References: <51E71D4F.5030502@marcuscom.com> <Pine.GSO.4.64.1307181059460.22570@sea.ntplx.net> <51E8061B.60906@marcuscom.com> <Pine.GSO.4.64.1307181118100.22570@sea.ntplx.net>
index | next in thread | previous in thread | raw e-mail
On 7/18/13 11:22 PM, Daniel Eischen wrote: > On Thu, 18 Jul 2013, Joe Marcus Clarke wrote: > >> On 7/18/13 11:09 AM, Daniel Eischen wrote: >>> 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. >>> >> >> Don't get me wrong, I agree with you. This behavior should result in >> EPERM. However, my comment was more on the portability side to >> maintain >> parity with Linux in order to support the 3rd party code people >> wanting >> to run on FreeBSD. We can workaround it in some cases, but I was >> floating up to you guys to perhaps create a broader workaround. > > If it is not a robust mutex, the behavior _is_ undefined, so I > think Linux is allowed to return 0 (no error), just as FreeBSD > is allowed to return an error. I will check Solaris 10 later > to see what it does. > > How many cases of this are we seeing in ports? How hard is > it to upstream portability fixes to them - are they usually > willing to accept these types of fixes? I think the answer would be to declare a new type of mutex that allows this ant document it as to only be used in broken linux code. don't know how much work it would be however.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51E80FF3.2080101>