svn commit: r49022 - head/en_US.ISO8859-1/htdocs/news/status
Dru Lavigne <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.cvs.doc |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected]. Reviewed by: [email protected] 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>[email protected]</email> + </person> + <person> + <name> + <given>Ed</given> + <common>Maste</common> + </name> + <email>[email protected]</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> _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-doc-all To unsubscribe, send any mail to "[email protected]"