Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Jul 2013 18:02:20 +0200
From:      Jilles Tjoelker <jilles@stack.nl>
To:        Joe Marcus Clarke <marcus@marcuscom.com>
Cc:        Daniel Eischen <deischen@freebsd.org>, Koop Mast <kwm@rainbow-runner.nl>, freebsd-threads@freebsd.org
Subject:   Re: Mutexes and error checking
Message-ID:  <20130721160220.GA38417@stack.nl>
In-Reply-To: <51EB5EC4.6050802@marcuscom.com>
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> <Pine.GSO.4.64.1307182144030.23634@sea.ntplx.net> <Pine.GSO.4.64.1307190152440.25756@sea.ntplx.net> <51EB5EC4.6050802@marcuscom.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sun, Jul 21, 2013 at 12:08:36AM -0400, Joe Marcus Clarke wrote:
> On 7/19/13 1:55 AM, Daniel Eischen wrote:
> > It seems Solaris behaves like Linux with PTHREAD_MUTEX_NORMAL
> > and _unlocking_ mutexes owned by other threads (dead or not).
> > Solaris only returns EPERM for PTHREAD_MUTEX_ERRORCHECK
> > mutexes.

> Given that, should we do the same?

According to http://sourceware.org/glibc/wiki/LockElisionGuide, it seems
like glibc wants to change behaviour here. If a mutex is implemented via
some sort of transactional memory, it may not work correctly if the
mutex is used as a semaphore with a different thread unlocking it. In
particular, attempting to commit a transaction via the XEND instruction
will cause a general protection fault if no transaction is in progress.
Adding software checks against these conditions will use up valuable
transactional memory tracking space.

So I think allowing pthread_mutex_unlock() by a different thread would
be a step backwards.

-- 
Jilles Tjoelker



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20130721160220.GA38417>