Bruno Haible via Gnulib discussion list <bug-gnulib@gnu.org> writes:
> The code of module 'asyncsafe-spin' consists of a multithread-safe spin lock
> implementation (that works fine even on native Windows), with an add-on
> intented to make it async signal safe (this part does not work reliably on
> native Windows).
>
> This suggests that it makes sense to rebase 'asyncsafe-spin' on top of a
> module 'spin', that implements purely the multithread-safe spin locks.
Thanks. I agree that spinlocks belong in glthreads with the other
synchronization primitives.
One thing that isn't new but was brought to my attention looking at
these patches:
> +static void
> +memory_barrier (void)
> +{
> +# if defined __GNUC__ || defined __clang__ || __SUNPRO_C >= 0x590 ||
> defined __TINYC__
> +# if defined __i386 || defined __x86_64__
> +# if defined __TINYC__ && defined __i386
> + /* Cannot use the SSE instruction "mfence" with this compiler. */
> + asm volatile ("lock orl $0,(%esp)");
> +# else
> + asm volatile ("mfence");
> +# endif
> +# endif
> +# if defined __sparc
> + asm volatile ("membar 2");
> +# endif
> +# else
> +# if defined __i386 || defined __x86_64__
> + asm ("mfence");
> +# endif
> +# if defined __sparc
> + asm ("membar 2");
> +# endif
> +# endif
> +}
Wouldn't it be better to use '__asm__' here and in the other functions
using inline assembly?
Since 'asm' only works when using one of the GNU standards
(e.g. -std=gnu23).
I ran into this issue recently compiling GNU Guile which does not yet
support C23 compilers which is the default since GCC 15. My solution was
to run './configure CFLAGS='-std=c99''. But ran into a compiler error
where 'asm ("r12")' was used to force a variable into the register.
Collin
