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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130721160220.GA38417>