| /* Commit an elided pthread lock. |
| Copyright (C) 2014-2018 Free Software Foundation, Inc. |
| 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/>. */ |
| |
| #include <pthreadP.h> |
| #include <lowlevellock.h> |
| #include <htm.h> |
| |
| int |
| __lll_unlock_elision(int *futex, short *adapt_count, int private) |
| { |
| /* If the lock is free, we elided the lock earlier. This does not |
| necessarily mean that we are in a transaction, because the user code may |
| have closed the transaction, but that is impossible to detect reliably. |
| Relaxed MO access to futex is sufficient because a correct program |
| will only release a lock it has acquired; therefore, it must either |
| changed the futex word's value to something !=0 or it must have used |
| elision; these are actions by the same thread, so these actions are |
| sequenced-before the relaxed load (and thus also happens-before the |
| relaxed load). Therefore, relaxed MO is sufficient. */ |
| if (atomic_load_relaxed (futex) == 0) |
| { |
| __libc_tend (); |
| } |
| else |
| { |
| /* Update the adapt_count while unlocking before completing the critical |
| section. adapt_count is accessed concurrently outside of a |
| transaction or a critical section (e.g. in elision-lock.c). So we need |
| to use atomic accesses. However, the value of adapt_count is just a |
| hint, so relaxed MO accesses are sufficient. |
| If adapt_count would be decremented while locking, multiple |
| CPUs, trying to lock the acquired mutex, will decrement adapt_count to |
| zero and another CPU will try to start a transaction, which will be |
| immediately aborted as the mutex is locked. |
| The update of adapt_count is done before releasing the lock as POSIX' |
| mutex destruction requirements disallow accesses to the mutex after it |
| has been released and thus could have been acquired or destroyed by |
| another thread. */ |
| short adapt_count_val = atomic_load_relaxed (adapt_count); |
| if (adapt_count_val > 0) |
| atomic_store_relaxed (adapt_count, adapt_count_val - 1); |
| |
| lll_unlock ((*futex), private); |
| } |
| return 0; |
| } |
