On Tue, Nov 12, 2002 at 07:01:43AM -0000, Nishant Sharma wrote: [nishant, you may wish to fix your mail user agent or mail server; I received a copy of this mail sent directly to me, and the headers did not mention kernelnewbies, and the email sent to kernelnewbies didn't mention me..] > So in effect it is required for ordering of the I/O > and memory refrences across crucial pieces of code (and this is > where _prefething_ etc comes into play) Yes. :) > I dont xactly get u here ;). Firstly ive seen in the Linux code > that i dont need to place a __volatile__ for the barrier > implementation code and it is being used because of a gcc bug, so > it is not supposed to be there ?? is it ?? The kernel is very specific to gcc bugs; as far as I can tell, the __volatile__ is required for the barrier. :) > Secondly, in IA32 a locked instruction is guarantees u a total > ordering around that instruction (and CPUID inst too guarantees > that). So when i need a barrier across two insts ... what code > will the barrier() expand to .. > sth like -- > write A > mb() // barrier > read B > > > Sorry for bothering ... i might be totally wrong here ..:) That sounds right to me.. but of course, if the read of B doesn't depend on the write of A, leaving out the memory barrier is the way to go. :) Heh heh heh. As far as I can tell, the best usage is in functions like set_task_state, where it is required the state get updated before other C statements get executed, and in unlocking critical sections of code, when the final changes to variables are expected to have finished. (I'm not sure if current versions of linux have this fixed or not. heh. :) -- http://www.wirex.com/
Attachment:
pgp00207.pgp
Description: PGP signature
