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