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

Thu Jun 30 14:41:00 UTC 2016

Author: dru
Date: Thu Jun 30 14:40:58 2016
New Revision: 49022
URL: https://svnweb.freebsd.org/changeset/doc/49022

Log:
  Add robust mutexes report from kib at FreeBSD.org.
  
  Reviewed by: wblock at freebsd.org
  Sponsored by: iXsystems

Modified:
  head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml

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

--- head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml	Wed Jun 29 12:43:37 2016	(r49021)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml	Thu Jun 30 14:40:58 2016	(r49022)
@@ -244,4 +244,86 @@
 	interest.</task>
     </help>
   </project>
+
+  <project cat='proj'>
+    <title>Robust Mutexes</title>
+
+    <contact>
+      <person>
+	<name>
+	  <given>Konstantin</given>
+	  <common>Belousov</common>
+	</name>
+	<email>kib at FreeBSD.org</email>
+      </person>
+      <person>
+	<name>
+	  <given>Ed</given>
+	  <common>Maste</common>
+	</name>
+	<email>emaste at FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>Now that the process-shared locks are implemented for our
+	POSIX threads implementation library, <tt>libthr</tt>,
+	the only major lacking feature for POSIX compliance is robust
+	mutexes.  Robust mutexes allow the application to detect, and
+	theoretically, recover from crashes which occur while
+	modifying the shared state.  The supported model is to protect
+	shared state by a <tt>pthread_mutex</tt>, and the crash is
+	detected as the thread termination while owning the mutex.  A
+	thread might terminate alone, or it could be killed due to the
+	termination of the containing process.   As such, the robust
+	attribute is applicable to both process-private and -shared
+	mutexes.</p>
+
+      <p>An application must be specifically modified to handle and
+	recover from failures.  The <tt>pthread_mutex_lock()</tt>
+	function may return new error <tt>EOWNERDEAD</tt>, which
+	indicates that the previous owner of the lock terminated while
+	still owning the lock.  Despite returning the non-zero value,
+	the lock is granted to the caller.  In the simplest form, an
+	application may detect the error and refuse to operate until
+	the persistent shared data is recovered, such as by manual
+	reinitialization.  More sophisticated applications could try
+	to automatically recover from the condition, in which case
+	<tt>pthread_mutex_consistent(3)</tt> must be called on the
+	lock before the unlock.  However, such recovery can be
+	considered to be very hard.  Still, even the detection of
+	inconsistent shared state is useful, since it avoids further
+	corruption and random faults of the affected application.
+      </p>
+
+      <p>It is curious but not unexpected that this interface is not
+	used widely.  The only real-life application which utilizes it
+	is Samba.  Using Samba with an updated FreeBSD base uncovered
+	minor bugs both in the FreeBSD robustness implementation, and
+	in Samba itself.</p>
+
+      <p>It is believed that <tt>libthr</tt> in FreeBSD 11 is
+	POSIX-compliant for large features.  Further work is planned
+	to look at the lock structures inlining to remove overhead
+	and improve performance of the library.</p>
+
+      <p>Most of the implementation of the robustness feature
+	consisted of making small changes in the lock and unlock
+	paths, both in <tt>libthr</tt> and in <tt>kern_umtx.c</tt>.
+	This literally required reading all of the code dealing with
+	mutexes and conditional variables, which was something I
+	wanted to help future developers with.  In the end, with the
+	help of Ed Maste, the man pages for <tt>umtx(2)</tt> and all
+	<tt>thr*(2)</tt> syscalls were written and added to the base
+	system's documentation set.
+      </p>
+    </body>
+
+    <sponsor>The FreeBSD Foundation</sponsor>
+
+    <help>
+      <task>Use the implementation in real-word applications and
+	report issues.</task>
+    </help>
+  </project>
 </report>
