Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Jul 2013 19:39:37 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Jilles Tjoelker <jilles@stack.nl>
Cc:        Joe Marcus Clarke <marcus@marcuscom.com>, Daniel Eischen <deischen@freebsd.org>, freebsd-threads@freebsd.org, Koop Mast <kwm@rainbow-runner.nl>
Subject:   Re: Mutexes and error checking
Message-ID:  <20130721163937.GD5991@kib.kiev.ua>
In-Reply-To: <20130721160220.GA38417@stack.nl>
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> <20130721160220.GA38417@stack.nl>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

--oFGQ2VdWvpciDCpb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 21, 2013 at 06:02:20PM +0200, Jilles Tjoelker wrote:
> 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.
>=20
> > Given that, should we do the same?
>=20
> 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.
For the XEND, Intel advises to use XTEST before to distinguish between
transactional and not transactional executions.

The elided unlock routine has to test the value of lock anyway,
to distinguish between elided and fallback locking.  Then, it is not
too hard to add a check for the case 'locked, but not by us', since
we have to check to avoid XEND for non-elided locks already.

>=20
> So I think allowing pthread_mutex_unlock() by a different thread would
> be a step backwards.
But this is true regardless of the TSX.

--oFGQ2VdWvpciDCpb
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (FreeBSD)

iQIcBAEBAgAGBQJR7A7IAAoJEJDCuSvBvK1BsZ4P/jSfrnAgJcy4h2RRdMpzLL4M
ERjZI2wEupkjF45NVayRVx9uBDzyd5R7CCL/uK164/9JeHYkDPSZ7XeMWZwpRMTs
h7ErRco8mrThqh0nuReIw99vJUTA51xF7ZQhiTVTjIsR1A/SQrzBIMMpGkY0nGvT
HGV4NK8fXMas8b5Gcsg+k0kyidyGqt6cql+/iaNL6ANfh8SbOJM9//u0PHVTzMZu
jmYO81SNOjl9M8mC3qmDJlbFS5zAHlsIuB6NhEkTg3yg9ZB+WpBwGz6cPAsyFa5L
G3FR4d6PKiJjypHI8teAlM7Ne8WiEw0sXs1HocBvY+rDHIl/LcCqjc6Wu7UYClL8
fFxpxJYiJyqOaSEFwmSJ7yf8dD1PC2rKpU0VnOQZp8/I6KxjqyA0HFYoPEvjwqRf
C15tstROA2gPM1ODjoUuOczk9hhMbSJuCrFXgeTjzsCtVJXcMpky2EVaHAYvZJcl
ewRpmBv81673IEP4h875zna6mF0LWjv3fkSekrPGmiP4TVe22SpWybQ/LB4UnVMj
BYs4GCGcQe2QUFa+7FO1M90PqfQOmtz84xCFTYkyahR8V9ajQ+gyUUgSDsdJPyAO
jzAGjFJopTQ10SAOm1AT/wcCLxf6ZKmfg6j0scpSVEopIwQQsgo2J7kPdyA9TEvR
/WbO07t87hXfULlChIel
=M74n
-----END PGP SIGNATURE-----

--oFGQ2VdWvpciDCpb--



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