Memory Barrier

Thomas Doerfler Thomas.Doerfler at
Tue Sep 11 17:44:35 UTC 2007


Till Straumann schrieb:
>>>       _CPU_MSR_GET(msr);
>>>       new_msr = msr | MSR_EE;
>>>       _CPU_MSR_SET(new_msr);
>>>        ...........
>>>       ............
>>>       _CPU_MSR_SET(msr);
>> Hm, I think this is also not a problem.
>> The compiler is not allowed to move the assignments to "msr" and
>> "new_msr", because they are used in the next statements.
> The problem is that the compiler may move code from after
> _CPU_MSR_SET(msr) upstream to before it is set thus
> moving code into a section that is not protected from interrupts.
> Or it may ignore the fact that global variables could change
> between the first MSR_Set (enabling interrupts) and the
> second one (disabling interrupts).

Ok, Till, agreed. The sample lines Kate mentioned in her previous
posting made me think about problems concerning the "new_msr" and "msr"
variables. You are right that this operation needs a memory barrier to
avoid dangerous compiler optimizations.


embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at
PGP public key available on request

More information about the users mailing list