| libthr.3 (6a7016194d579fde78c09fdc9d5c4e7f476ea58f) | libthr.3 (f5b9747075a9b489226e2a911f8a1597f4b9d072) |
|---|---|
| 1.\" Copyright (c) 2005 Robert N. M. Watson | 1.\" Copyright (c) 2005 Robert N. M. Watson |
| 2.\" Copyright (c) 2014,2015 The FreeBSD Foundation, Inc. | 2.\" Copyright (c) 2014,2015,2021 The FreeBSD Foundation, Inc. |
| 3.\" All rights reserved. 4.\" 5.\" Part of this documentation was written by 6.\" Konstantin Belousov <kib@FreeBSD.org> under sponsorship 7.\" from the FreeBSD Foundation. 8.\" 9.\" Redistribution and use in source and binary forms, with or without 10.\" modification, are permitted provided that the following conditions --- 13 unchanged lines hidden (view full) --- 24.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 25.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 26.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 27.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 28.\" SUCH DAMAGE. 29.\" 30.\" $FreeBSD$ 31.\" | 3.\" All rights reserved. 4.\" 5.\" Part of this documentation was written by 6.\" Konstantin Belousov <kib@FreeBSD.org> under sponsorship 7.\" from the FreeBSD Foundation. 8.\" 9.\" Redistribution and use in source and binary forms, with or without 10.\" modification, are permitted provided that the following conditions --- 13 unchanged lines hidden (view full) --- 24.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 25.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 26.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 27.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 28.\" SUCH DAMAGE. 29.\" 30.\" $FreeBSD$ 31.\" |
| 32.Dd May 5, 2020 | 32.Dd October 1, 2021 |
| 33.Dt LIBTHR 3 34.Os 35.Sh NAME 36.Nm libthr 37.Nd "1:1 POSIX threads library" 38.Sh LIBRARY 39.Lb libthr 40.Sh SYNOPSIS --- 213 unchanged lines hidden (view full) --- 254of the user-provided signal handler is unsafe. 255An example of such a situation is owning the internal library lock. 256When a signal is delivered while the signal handler cannot be safely 257called, the call is postponed and performed until after the exit from 258the critical section. 259This should be taken into account when interpreting 260.Xr ktrace 1 261logs. | 33.Dt LIBTHR 3 34.Os 35.Sh NAME 36.Nm libthr 37.Nd "1:1 POSIX threads library" 38.Sh LIBRARY 39.Lb libthr 40.Sh SYNOPSIS --- 213 unchanged lines hidden (view full) --- 254of the user-provided signal handler is unsafe. 255An example of such a situation is owning the internal library lock. 256When a signal is delivered while the signal handler cannot be safely 257called, the call is postponed and performed until after the exit from 258the critical section. 259This should be taken into account when interpreting 260.Xr ktrace 1 261logs. |
| 262.Sh PROCESS-SHARED SYNCHRONIZATION OBJECTS 263In the 264.Li libthr 265implementation, 266user-visible types for all synchronization objects (e.g. pthread_mutex_t) 267are pointers to internal structures, allocated either by the corresponding 268.Fn pthread_<objtype>_init 269method call, or implicitly on first use when a static initializer 270was specified. 271The initial implementation of process-private locking object used this 272model with internal allocation, and the addition of process-shared objects 273was done in a way that did not break the application binary interface. 274.Pp 275For process-private objects, the internal structure is allocated using 276either 277.Xr malloc 3 278or, for 279.Xr pthread_mutex_init 3 , 280an internal memory allocator implemented in 281.Nm . 282The internal allocator for mutexes is used to avoid bootstrap issues 283with many 284.Xr malloc 3 285implementations which need working mutexes to function. 286The same allocator is used for thread-specific data, see 287.Xr pthread_setspecific 3 , 288for the same reason. 289.Pp 290For process-shared objects, the internal structure is created by first 291allocating a shared memory segment using 292.Xr _umtx_op 2 293operation 294.Dv UMTX_OP_SHM , 295and then mapping it into process address space with 296.Xr mmap 2 297with the 298.Dv MAP_SHARED 299flag. 300The POSIX standard requires that: 301.Bd -literal 302only the process-shared synchronization object itself can be used for 303performing synchronization. It need not be referenced at the address 304used to initialize it (that is, another mapping of the same object can 305be used). 306.Ed 307.Pp 308With the 309.Fx 310implementation, process-shared objects require initialization 311in each process that use them. 312In particular, if you map the shared memory containing the user portion of 313a process-shared object already initialized in different process, locking 314functions do not work on it. 315.Pp 316Another broken case is a forked child creating the object in memory shared 317with the parent, which cannot be used from parent. 318Note that processes should not use non-async-signal safe functions after 319.Xr fork 2 320anyway. |
|
| 262.Sh SEE ALSO 263.Xr ktrace 1 , 264.Xr ld-elf.so.1 1 , 265.Xr getrlimit 2 , 266.Xr errno 2 , 267.Xr thr_exit 2 , 268.Xr thr_kill 2 , 269.Xr thr_kill2 2 , --- 30 unchanged lines hidden --- | 321.Sh SEE ALSO 322.Xr ktrace 1 , 323.Xr ld-elf.so.1 1 , 324.Xr getrlimit 2 , 325.Xr errno 2 , 326.Xr thr_exit 2 , 327.Xr thr_kill 2 , 328.Xr thr_kill2 2 , --- 30 unchanged lines hidden --- |