On 3/13/22 09:57, Warner Losh wrote:
On Sun, Mar 13, 2022, 10:47 AM Richard Henderson <richard.hender...@linaro.org <mailto:richard.hender...@linaro.org>> wrote:On 3/12/22 20:59, Warner Losh wrote: > FreeBSD's pthread_mutex is shared between the kernel and user land. > So it does a compare and set to take the lock. Uncontested and unheld > locks will mean we've taken the lock and return. Contested locks > are kicked to the kernel to wait. When userland releases the lock > it signals the kernel to wakeup via a system call. The kernel then > does a cas to try to acquire the lock. It either returns with the lock > held, or goes back to sleep. This we have atomics operating both in > the kernel (via standard host atomics) and userland atomics done > via start/end_exclusive. You need to use standard host atomics for this case.Or use the start/end_exclusive for both by emulating the kernel call, I presume? It's the mixing that's the problem, right?
Well, preferably no. Use start/end_exclusive only when you have no alternative, which for a simple CAS should not be the case on any FreeBSD host.
Using start/end_exclusive is entirely local to the current process, and means you don't have atomicity across processes. Which can cause problems when emulating an entire chroot.
r~
