The kernel's documentation about memory barriers is rather skimpy. I
gather that rmb() guarantees that all preceding reads will have completed
before any following reads are made, and wmb() guarantees that all
preceding writes will have completed before any following writes are made.
I also gather that mb() is essentially the same as rmb() and wmb() put
together.
But suppose I need to prevent a read from being moved past a write? It
doesn't look like either rmb() or wmb() will do this. And if mb() is the
same as "rmb(); wmb();" then it won't either. So what's the right thing
to do?
Alan Stern
On Thu, 2 Feb 2006, Alan Stern wrote:
> The kernel's documentation about memory barriers is rather skimpy. I
> gather that rmb() guarantees that all preceding reads will have completed
> before any following reads are made, and wmb() guarantees that all
> preceding writes will have completed before any following writes are made.
> I also gather that mb() is essentially the same as rmb() and wmb() put
> together.
>
> But suppose I need to prevent a read from being moved past a write? It
> doesn't look like either rmb() or wmb() will do this. And if mb() is the
> same as "rmb(); wmb();" then it won't either. So what's the right thing
> to do?
>
> Alan Stern
If you use the correct macros for device I/O (in other words
the operations are upon volatile objects), there can never
be any re-ordering of any associated code.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.66 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
To unsubscribe
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
>>>>> "Alan" == Alan Stern <[email protected]> writes:
Alan> The kernel's documentation about memory barriers is rather
Alan> skimpy. I gather that rmb() guarantees that all preceding
Alan> reads will have completed before any following reads are
Alan> made, and wmb() guarantees that all preceding writes will
Alan> have completed before any following writes are made. I also
Alan> gather that mb() is essentially the same as rmb() and wmb()
Alan> put together.
Most of this is correct, except that mb() is stronger than just rmb()
and wmb() put together. All memory operations before the mb() will
complete before any operations after the mb(). A better way to
understand this is to look at the sparc64 definition:
#define mb() \
membar_safe("#LoadLoad | #LoadStore | #StoreStore | #StoreLoad")
Alan> But suppose I need to prevent a read from being moved past a
Alan> write? It doesn't look like either rmb() or wmb() will do
Alan> this. And if mb() is the same as "rmb(); wmb();" then it
Alan> won't either. So what's the right thing to do?
As described above, mb() will work in this case. It actually
guarantees more than you need, so you could conceivably define a new
primitive, but the current barriers are hard enough for people to
figure out ;)
- R.
On Thu, 2 Feb 2006, Roland Dreier wrote:
> Most of this is correct, except that mb() is stronger than just rmb()
> and wmb() put together. All memory operations before the mb() will
> complete before any operations after the mb(). A better way to
> understand this is to look at the sparc64 definition:
>
> #define mb() \
> membar_safe("#LoadLoad | #LoadStore | #StoreStore | #StoreLoad")
Thanks for the explanation. Is there any appropriate place, say in
Documentation/, where these things could be spelled out more completely?
Alan Stern
On Thu, 2 Feb 2006, Alan Stern wrote:
> On Thu, 2 Feb 2006, Roland Dreier wrote:
>
> > Most of this is correct, except that mb() is stronger than just rmb()
> > and wmb() put together. All memory operations before the mb() will
> > complete before any operations after the mb(). A better way to
> > understand this is to look at the sparc64 definition:
> >
> > #define mb() \
> > membar_safe("#LoadLoad | #LoadStore | #StoreStore | #StoreLoad")
>
> Thanks for the explanation. Is there any appropriate place, say in
> Documentation/, where these things could be spelled out more completely?
Info could be added to Documentation/DocBook/kernel-locking.tmpl
which already has some barrier info.
--
~Randy