Re: armv7-on-aarch64 stuck at urdlck

On 23.07.2024 0:50, Konstantin Belousov wrote:
> On Mon, Jul 22, 2024 at 09:36:00PM +0200, Michal Meloun wrote:
>> IMHO, -O2 shouldn't be able to modify function arguments for public
>> functions, so <guessing> this memory corruption fits perfectly with the
>> observed behavior</guessing>.
>>
>> But , out of curiosity, a quick look at _thr_rwlock_tryrdlock() in
>> thr_umtx.h:208 makes me wonder: How is the "state" variable inside the loop
>> guaranteed to be updated? IMHO nothing inside the loop emits a global memory
>> modification attribute, so the compiler is free to move the assignment to a
>> "state" variable outside the loop.
>>
> 
> I think that you are formally right, because there is only the _acq
> atomic in the loop body, an evil compiler is allowed to move all loads
> before the start of the loop iteration.
> 
> But, since e.g. on arm32 atomic_cmpset_acq implementation contains dmb()
> which provides the full barrier both for compiler memory accesses, and
> for hw, it is not the case (for arm32).

Thank you for the explanation. I didn't check the implementation of 
atomic_cmpset_acq and completely forgot that it has dmb() inside. My 
memory really needs a better refresh....