1 files changed, 61 insertions, 0 deletions
diff --git a/REORG.TODO/sysdeps/unix/sysv/linux/s390/elision-unlock.c b/REORG.TODO/sysdeps/unix/sysv/linux/s390/elision-unlock.c
new file mode 100644
index 0000000000..c062d71b77
--- /dev/null
+++ b/REORG.TODO/sysdeps/unix/sysv/linux/s390/elision-unlock.c
@@ -0,0 +1,61 @@
+/* Commit an elided pthread lock.
+   Copyright (C) 2014-2017 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;
+}