|
From: | Marc Nieper-Wißkirchen |
Subject: | Re: Atomic operations |
Date: | Fri, 12 Aug 2022 18:39:21 +0200 |
Em sex., 12 de ago. de 2022 às 11:45, Marc Nieper-Wißkirchen
<marc.nieper+gnu@gmail.com> escreveu:
>
> I agree that casr/tasr (maybe also casi/tasi) are the most important instructions. As long as it can be implemented on the supported set of CPUs, I don't see why we shouldn't have _c, _s, _i, _l variants alongside the word-size variant.
>
> The only problem I see is that an atomic store in one thread together with an atomic load of the same memory location in another thread will become costly if release-acquire semantics are needed. This can be emulated with casr/tasr (I assume that their semantics is sequentially consistent) but this is a costly operation while on many important CPUs like x86 all release-acquire semantics actually do not need special instructions.
At first, my idea would be to implement tas (test and set). During
this exercise,
learn more detailed about what the different backends provide.
Then, implement cas (compare and swap), that also requires a new pattern for
4 argument instructions.
> It is probably enough to provide a global release and an acquire instruction (which does the equivalent of C11's atomic_thread_fence (memory_order_release) and atomic_thread_fence (memory_order_acquire), respectively). (These would be no-ops on x86, for example.) And maybe also an operation corresponding to atomic_thread_fence (memory_order_seq_cst).
And later, consider any kind of transactional memory support. That will depend
on how much is required on software fallbacks.
This has very low priority for me, so, if you want to start, I can help :)
[Prev in Thread] | Current Thread | [Next in Thread] |