Should I use Release-Acquire ordering or Sequentially-consistent ordering to implement spinlock with atomic?

[Ruki]

I want to implement spinlock with atomic. Should I use Release-Acquire ordering or Sequentially-consistent ordering to ensure visibility for multicore?

I read the c11 atomic documentation (https://en.cppreference.com/w/c/atomic/memory_order), which only clearly shows the multicore visible to the Sequentially-consistent ordering.

> Total sequential ordering requires a full memory fence CPU instruction on all multi-core systems. This may become a performance bottleneck since it forces the affected memory accesses to propagate to every core.

[David Brown]

Acquire and release ordering are usually what you want for locks -
/acquire/ the lock, then /release/ it.

But why are you implementing spinlocks ? Are you writing your own OS?
If not, then usually the OS's own spinlocks will be a better choice.

(If this is for learning purposes or fun, then of course that is an
excellent reason.)

[Ruki]

在 2019年8月28日星期三 UTC+8下午3:15:32，David Brown写道：

Not all os provide spinlocks, and like nginx, they also use their own spinlock implementation.

[Bonita Montero]

Use acquire-semantics when locking, release-semantics when unlocking.

[Chris M. Thomasson]

What type of spinlock are you going for? A Dekker?

[Chris M. Thomasson]

On 8/28/2019 1:56 AM, Bonita Montero wrote:
> Use acquire-semantics when locking, release-semantics when unlocking.

Some special spinlocks require sequential consistency. Even an x86
cannot handle a store followed by a load to another location. Some locks
depend on that. IBM's hazard pointers do.

[Bonita Montero]

>> Use acquire-semantics when locking, release-semantics when unlocking.

> Some special spinlocks require sequential consistency. Even an x86
> cannot handle a store followed by a load to another location. Some
> locks depend on that. IBM's hazard pointers do.

I think he is talking about a usual mutex.

[Chris M. Thomasson]

Well, then acquire/release works. But its not sufficient for certain
things. The usual pattern goes:
___________________________
LOCK(); // Atomically gain mutual exclusion

ACQUIRE_MEMBAR();

// critical section

RELEASE_MEMBAR();

UNLOCK(); // Atomically release mutual exclusion
___________________________


Now, some spinlocks need a membar in the LOCK() logic itself. And can
avoid using the acquire. Something like:
___________________________
LOCK_WITH_MEMBAR(); // Gain mutual exclusion, using something special...

//ACQUIRE_MEMBAR(); // not needed

// critical section

RELEASE_MEMBAR();

UNLOCK(); // Atomically release mutual exclusion
___________________________

[Jorgen Grahn]

I note that that doesn't really answer David's question.

Weird that nginx implements spinlocks, when it also advertises itself
as single-threaded. I don't see the use of spinlocks in a situation
where there's only one thread of execution.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .