svn commit: r48585 - head/en_US.ISO8859-1/htdocs/news/status

Tue Apr 12 21:50:03 UTC 2016

Author: wblock
Date: Tue Apr 12 21:50:01 2016
New Revision: 48585
URL: https://svnweb.freebsd.org/changeset/doc/48585

Log:
  Add process-shared locks report from Konstantin Belousov
  <kostikbel at gmail.com>.

Modified:
  head/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml

Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml
==============================================================================

--- head/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml	Tue Apr 12 21:48:48 2016	(r48584)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml	Tue Apr 12 21:50:01 2016	(r48585)
@@ -748,4 +748,89 @@
       </task>
     </help>
   </project>
+
+  <project cat='proj'>
+    <title>Process-Shared locks for libthr</title>
+
+    <contact>
+      <person>
+	<name>
+	  <given>Konstantin</given>
+	  <common>Belousov</common>
+	</name>
+
+	<email>kib at FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>POSIX specifies several kinds of pthread locks, for this
+	report the private and process-shared variants are considered.
+	Private locks can be used only by the threads of the same
+	process, which share the address space.  Process-shared locks
+	can be used by threads from any process, assuming the process
+	can map the lock memory into its address space.</p>
+
+      <p>Our libthr, the library implementing the POSIX threads and
+	locking operations, uses a pointer as the internal
+	representation behind a lock.  The pointer contains the
+	address of the actual structure carrying the lock.  This has
+	unfortunate consequences for implementing the
+	<tt>PTHREAD_PROCESS_SHARED</tt> attribute for locks, since
+	really only the pointer is shared when the lock is mapped into
+	distinct address spaces.</p>
+
+      <p>A common opinion was that we have no choice but to break the
+	libthr Application Binary Interface (ABI) by changing the lock
+	types to be the actual lock structures (and padding for future
+	ABI extension).  This is very painful for users, as our
+	previous experience with non-versioned libc and libc_r
+	shown.</p>
+
+      <p>Instead, I proposed and implemented a scheme where
+	process-shared locks can be implemented without breaking the
+	ABI.  The lock memory is used as a key into the system-global
+	hash of the shared memory objects (off-pages), which carry the
+	real lock structures.</p>
+
+      <p>New umtx operations to create or look up the shared object,
+	by the memory key, were added.  Libthr is modified to lookup
+	the object and use it for shared locks, instead of using
+	malloc() as for private locks.</p>
+
+      <p>The pointer value in the user-visible lock type contains a
+	canary for shared locks.  Libthr detects the canary and
+	switches into the shared-lock mode.</p>
+
+      <p>The proposal of inlining the lock structures, besides the
+	drawbacks of breaking ABI, has its merits.  Most important,
+	the inlining avoids the need of indirection.  Another
+	important advantage over the off-page page approach is that no
+	off-page object needs to be maintained, and the lifecycle of
+	the shared lock naturally finishes with the destruction of the
+	shared memory, without explicit cleanup.  Right now, off-pages
+	hook into vm object termination to avoid leakage, but long
+	liviness of the vnode vm object prolonges the off-page
+	existence for shared locks backed by files, however unlikely
+	they may be.</p>
+
+      <p>Libthr with inlined locks become informally known as libthr2
+	project, since the library name better be changed instead of
+	only bumping the library version.  The rtld should ensure that
+	libthr and libthr2 do not become simultaneously loaded into a
+	single address space.</p>
+    </body>
+
+    <sponsor>The FreeBSD Foundation</sponsor>
+
+    <help>
+      <task>
+	<p>Implement robust mutexes.</p>
+      </task>
+
+      <task>
+	<p>Evaluate and implement libthr2.</p>
+      </task>
+    </help>
+  </project>
 </report>
