On 5/8/07, mohanlal jangir <mohanlal@xxxxxxxxxxx> wrote:
heh... this means it works :-).
Thank you for confirming Mohan.
Thanks Eric.
~psr
Hi Eric,
On 5/8/07, Erik Mouw <mouw@xxxxxxxxxxxx> wrote:
>
> On Tue, May 08, 2007 at 08:51:22AM +0530, pradeep singh wrote:
> > On 5/7/07, Erik Mouw < mouw@xxxxxxxxxxxx> wrote:
> > >On Mon, May 07, 2007 at 09:25:02PM +0530, Linux Learner wrote:
> > >> Does -O2 affect SMP safeness of above code?
> > >
> > >They're not safe with any optimisation level because the compiler is
> > >free to reorder instructions around your own lock. Use the kernel
> > >supplied locking primitives.
> >
> > Eric, but the lock primitive acts as a memory barrier , isn't it?
>
> For the CPU, yes. But unless you tell the compiler that your inline
> assembly has certain side effects the compiler can still reorder it
> with other instructions.
>
> > AFAIK gcc still optimises the code even if it encounters a volatile
> > after asm but that may be the case when gcc is absolutely sure that
> > the code inside is unreachable. Isn't it?
>
> Volatile isn't enough, you really need to tell the compiler the
> instruction affects memory.
> In other words, I hope you mean i should rather include "memory"(*x) ,
> isn't it?
> Can you please help me with understanding if memory is the correct
> cloberring directive to be used in such cases to fake a side effect to the
> gcc ?
Yes, you are right. I tried it with memory clobbering directive and then it
worked as expected (without reordering).
heh... this means it works :-).
Thank you for confirming Mohan.
Thanks Eric.
~psr
-Mohan
--
play the game