Re: locking on SMP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 5/8/07, mohanlal jangir <mohanlal@xxxxxxxxxxx> wrote:


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

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux