os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add robust mutexes report from kib@FreeBSD.org.

Browse source 
Reviewed by: wblock@freebsd.org
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne 2016-06-30 14:40:58 +00:00
parent 716ed4e857
commit 75fa73dc6c
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=49022
1 changed files with 82 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

82
en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml
View file

@ -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@FreeBSD.org</email>
</person>
<person>
<name>
<given>Ed</given>
<common>Maste</common>
</name>
<email>emaste@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>