On Sun, Mar 13, 2022 at 11:03 AM Richard Henderson < richard.hender...@linaro.org> wrote:
> 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. > So I was assuming that the cas instructions for arm use start/end_exclsive under the covers. Is that the case? Or is there something clever there I've overlooked and the start/end_exclusive stuff is only used for fallbacks? Warner
