Hi,
This is a text excerpt from the article [1].
Below paragraph I didn't understand quite well.Mainly in bold letters.Could
anybody please explain how this will lead to an infinite loop.
Atomicity
All modern processors offer atomic instructions. These special instructions
are crucial for synchronizing two or more concurrent tasks. As the name
implies, atomic instructions must be *indivisible* -- that's why they're so
handy for synchronization: they can't be preempted.
It turns out that in order for atomic instructions to perform correctly, the
addresses you pass them must be at least four-byte aligned. This is because
of a subtle interaction between atomic instructions and virtual memory.
If an address is unaligned, it requires at least two memory accesses. But
what happens if the desired data spans two pages of virtual memory? This
could lead to a situation where the first page is resident while the last
page is not. Upon access, in the middle of the instruction, a page fault
would be generated, executing the virtual memory management swap-in code,
destroying the atomicity of the instruction. To keep things simple and
correct, both the 68K and PowerPC require that atomically manipulated
addresses always be at least four-byte aligned.
*Unfortunately, the PowerPC does not throw an exception when atomically
storing to an unaligned address. Instead, the store simply always fails.
This is bad because most atomic functions are written to retry upon a failed
store, under the assumption they were preempted. These two circumstances
combine to where your program will go into an infinite loop if you attempt
to atomically store to an unaligned address. Oops.*
[1] http://www.ibm.com/developerworks/library/pa-dalign/.
--
With Regards
Subin Gangadharan
Everything should be made as simple as possible,but not simpler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110806/eb1d67a2/attachment.html
On Sat, Aug 6, 2011 at 10:17 PM, subin gangadharan
[off-list ref] wrote:
Hi,
This is a text excerpt from the article [1].
Below paragraph I didn't understand quite well.Mainly in bold letters.Could
anybody please explain how this will lead to an infinite loop.
It seems self-explanatory. Most atomic ops are written to retry upon a failed
store, and on PowerPC an atomic store to an unaligned address always fails,
thus the processor will infinitely try to store the value, without having
the chance to fix the unaligned access (as would have happened if an exception
was thrown).
Unfortunately, the PowerPC does not throw an exception when atomically
storing to an unaligned address. Instead, the store simply always fails.
This is bad because most atomic functions are written to retry upon a failed
store, under the assumption they were preempted. These two circumstances
combine to where your program will go into an infinite loop if you attempt
to atomically store to an unaligned address. Oops.
thanks,
Daniel.
On Sat, Aug 6, 2011 at 12:37 PM, Daniel Baluta [off-list ref]wrote:
On Sat, Aug 6, 2011 at 10:17 PM, subin gangadharan
[off-list ref] wrote:
quoted
Hi,
This is a text excerpt from the article [1].
Below paragraph I didn't understand quite well.Mainly in bold
letters.Could
quoted
anybody please explain how this will lead to an infinite loop.
It seems self-explanatory. Most atomic ops are written to retry upon a
failed
store, and on PowerPC an atomic store to an unaligned address always
fails,
thus the processor will infinitely try to store the value, without having
the chance to fix the unaligned access (as would have happened if an
exception
was thrown).
quoted
Unfortunately, the PowerPC does not throw an exception when atomically
storing to an unaligned address. Instead, the store simply always fails.
This is bad because most atomic functions are written to retry upon a
failed
quoted
store, under the assumption they were preempted. These two circumstances
combine to where your program will go into an infinite loop if you
attempt
quoted
to atomically store to an unaligned address. Oops.
thanks,
Daniel.
Thanks Daniel,
My bad, I was trying to connect the page fault explained before that
paragraph and this one.
Hence I got confused,again thanks for clarifying it.
--
With Regards
Subin Gangadharan
Everything should be made as simple as possible,but not simpler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110806/0dc46c67/attachment.html