glibc/sysdeps/unix/sysv/linux/x86/elision-trylock.c

76 lines
2.5 KiB
C
Raw Normal View History

Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
/* elision-trylock.c: Lock eliding trylock for pthreads.
Copyright (C) 2013-2018 Free Software Foundation, Inc.
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
<http://www.gnu.org/licenses/>. */
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
#include <pthread.h>
#include <pthreadP.h>
#include <lowlevellock.h>
#include "hle.h"
#include <elision-conf.h>
#define aconf __elision_aconf
/* Try to elide a futex trylock. FUTEX is the futex variable. ADAPT_COUNT is
the adaptation counter in the mutex. */
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
int
__lll_trylock_elision (int *futex, short *adapt_count)
{
/* Implement POSIX semantics by forbiding nesting
trylock. Sorry. After the abort the code is re-executed
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
non transactional and if the lock was already locked
return an error. */
_xabort (_ABORT_NESTED_TRYLOCK);
/* Only try a transaction if it's worth it. See __lll_lock_elision for
why we need atomic accesses. Relaxed MO is sufficient because this is
just a hint. */
if (atomic_load_relaxed (adapt_count) <= 0)
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
{
unsigned status;
if ((status = _xbegin()) == _XBEGIN_STARTED)
{
if (*futex == 0)
return 0;
/* Lock was busy. Fall back to normal locking.
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
Could also _xend here but xabort with 0xff code
is more visible in the profiler. */
_xabort (_ABORT_LOCK_BUSY);
}
if (!(status & _XABORT_RETRY))
{
/* Internal abort. No chance for retry. For future
locks don't try speculation for some time. See above for MO. */
if (atomic_load_relaxed (adapt_count)
!= aconf.skip_lock_internal_abort)
atomic_store_relaxed (adapt_count, aconf.skip_lock_internal_abort);
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
}
/* Could do some retries here. */
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
}
else
{
/* Lost updates are possible but harmless (see above). */
atomic_store_relaxed (adapt_count,
atomic_load_relaxed (adapt_count) - 1);
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
}
return lll_trylock (*futex);
}