Hi Eric,
On 5/8/07, Erik Mouw <mouw@xxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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 ?
Thank you for the reply
~psr
>
> > Will this optimization effect the memory barrier act of the lock prefix
> > here?
>
> A lock prefix doesn't automatically tell the compiler there is a memory
> barrier.
>
> Again, just use the kernel supplied functions (atomic_inc() and
> atomic_dec() in your particular case). First of all the functions are
> portable among architectures, second they will automatically be relaxed
> (or even optimised away) in the non-SMP case, and third they are well
> tested and debugged.
>
>
> Erik
>
> - --
> They're all fools. Don't worry. Darwin may be slow, but he'll
> eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG
v1.4.6 (GNU/Linux)
>
> iD8DBQFGQFzZ/PlVHJtIto0RAi/FAJ9ylZ/LG3P7FH6Q3WA4mlIuVJEhaQCZAUSY
> qQR5aTQcw62VPHjBtEP1oRM=
> =oVn1
> -----END PGP SIGNATURE-----
>
--
play the game
