[concurrency-interest] out of order execution on uniprocessor

raghuram nidagal raghuram.nidagal at gmail.com
Tue Dec 8 09:12:14 EST 2009

Is "out of order execution" relevant in case of a single processor. I see
the following extracts relating to single processors. Would appreciate if
somebody could clarify
what can be expected in a single processor case.

Discussing this in terms of caches, it may sound as if these issues only
affect multiprocessor machines. However, the reordering effects can be
easily seen on a single processor. It is not possible, for example, for the
compiler to move your code before an acquire or after a release. When we say
that acquires and releases act on caches, we are using shorthand for a
number of possible effects.

If you are generating code that is guaranteed to only run on a uniprocessor,
then you can probably skip the rest of this section. Because uniprocessors
preserve apparent sequential consistency, you never need to issue barriers
unless object memory is somehow shared with asynchrononously accessible IO
memory. This might occur with specially mapped java.nio buffers, but
probably only in ways that affect internal JVM support code, not Java code.
Also, it is conceivable that some special barriers would be needed if
context switching doesn't entail sufficient synchronization.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20091208/96f1bbaa/attachment.html>

More information about the Concurrency-interest mailing list