在 2021/1/19 上午11:54, Zebediah Figura (she/her) 写道: > > Do you mean that the writer should change the above code to e.g. > "__atomic_load_n(&var, ___ATOMIC_ACQUIRE)", or that the read already > implies acquire semantics? I didn't think that the latter was true, but > I don't trust that judgement; locking is way too hard... >
Yes. There isn't necessarily any locking. A notable example is x86, which is
very close to total
store ordering: Loading from a memory location implies acquire semantics.
> But even if the above code isn't correct, I don't think it's worth
> potentially breaking it.
>
If `var` is not declared `volatile` then it is definitely undesirable. GCC can
optimize it to an
infinite loop.
If `var` is declared `volatile`, this is still incorrect, but it was what
people wrote code back in
VC6 days. The `volatile` qualifier doesn't guarantee correct ordering if the
loop isn't executed *at
all*, so clobbering "memory" doesn't yield any benefit; but if the loop is
executed, `volatile`
reads cannot be optimized out, so it doesn't yield any harm, either.
>
> So here's a fun fact: if I change the statement
>
> __asm__ ("nop");
>
> to
>
> __asm__ ("nop":);
>
> then gcc will *not* reload ival. This is apparently the difference
> between "basic" and "extended" asm, which I was not previously aware of.
> I can't find it explicitly stated in gcc's documentation that basic asm
> always clobbers memory, but apparently it's the case.
>
> Of course, in that case, I'd encourage sticking with the explicitly
> documented behavior and using extended asm.
>
That's interesting. As you have pointed out, it prevents the compiler from
reusing a value loaded
earlier, but this probably isn't needed by `YieldProcessor()`; it's only
necessary for
`MemoryBarrier()`.
--
Best regards,
LH_Mouse
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
