https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #40 from admin_public at liblfds dot org --- On 03/11/2022 12:04, jakub at gcc dot gnu.org wrote: > --- Comment #38 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > Please see PR104688 . We got a response from Intel, where they guaranteed > atomicity of certain 16-byte load instructions for Intel CPUs with AVX > support. Now, it's been a quite a long time since I've delved into lock-free, and I have reason to doubt my earlier understanding anyway - so I may be *completely* wrong - but, as I recall, and, as I understood it, the "usual" atomic operations (i.e. non-AVX) are essential in that they force the honouring of any previously issued read/write barriers, as they force a read from, and write to, memory (well, I say memory - I mean to say, at least out to the cache coherency protocol). Will AVX do the same? > The current state is that on the libatomic side when ifuncs are possible we > use > those atomic loads etc. on Intel with AVX, and do what we used to do before > for > other CPUs. Yes. As I recall, this is the problem for me - if such lock-free is not available, mutexes or some such as used instead, and this is absolutely *not* okay, because their properties are completely different; if I have a lock-free data structure and I'm using it in the kernel and I'm not allowed to sleep, I *can't* use a sleep-based locking mechanism. Lock-free has unique properties and when those properties are needed, if they are not available, the only option is to fail to compile/build/run.
