On 3/13/22 09:57, Warner Losh wrote:
>
>
> On Sun, Mar 13, 2022, 10:47 AM Richard Henderson <richard.henderson@linaro.org
> <mailto:richard.henderson@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