svn commit: r48585 - head/en_US.ISO8859-1/htdocs/news/status
Warren Block <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.cvs.doc |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]>. 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>[email protected]</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> _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-doc-all To unsubscribe, send any mail to "[email protected]"