OK, sorry if I wasn't clear. I understand the mechanism with the library call,
but what I don't, is why the code below, where the load exclusive establishes
the address reservation and we do it until the store exclusive succeed doesn't
fix the problem.
1: LDREX r2, [r0]
STREX r1, r2, [r0]
> From: Yvan Roux [yvan.r...@linaro.org]
> Sent: 25 November 2012 19:51
> To: Ramana Radhakrishnan
> Cc: linaro-toolchain@lists.linaro.org
> Subject: Re: Atomic builtins questions
> > That is correct. The addresses need to be aligned as per the restrictions in
> > the
> That is correct. The addresses need to be aligned as per the restrictions in
> the architecture. Yes we could have an issue but software writers need to
> deal with it because IIUC you either have a huge performance penalty (x86 /
> lock prefix) or correctness issues (ARM, Powerpc) .
Ok thanks,
,
Ramana
From: Yvan Roux [mailto:yvan.r...@linaro.org]
Sent: 23 November 2012 10:29
To: Ramana Radhakrishnan
Cc: linaro-toolchain@lists.linaro.org
Subject: Re: Atomic builtins questions
Hi Ramana and Peter,
There is no issue in the first case. You are correct that the dmb's there are
to e
Hi Ramana and Peter,
There is no issue in the first case. You are correct that the dmb’s there
> are to ensure the sequential consistency as you’d want to see with
> __ATOMIC_SEQ_CST in the call to the builtin. However what you must remember
> is that STRs are guaranteed to be single-copy atomic
On 22 November 2012 20:31, Ramana Radhakrishnan
wrote:
> On systems with LPAE enabled, ldrd and strd are also guaranteed to be atomic
> copies from 64 bit aligned addresses
Not quite (though this is splitting a rather fine hair). ldrd/strd are 64 bit
single-copy atomic for 64 bit aligned addresse
Hi Yvan,
There is no issue in the first case. You are correct that the dmb's there are
to ensure the sequential consistency as you'd want to see with __ATOMIC_SEQ_CST
in the call to the builtin. However what you must remember is that STRs are
guaranteed to be single-copy atomic by the architect
