[concurrency-interest] out of order execution on uniprocessor

Boehm, Hans hans.boehm at hp.com
Tue Dec 8 13:37:36 EST 2009

If you are writing Java code, it doesn't matter whether you're on a uniprocessor.  The hardware generally won't visibly reorder memory accesses on a uniprocessor, but the compiler still will.  And you'd be hard pressed to tell the difference.

If you are building a JVM, then it does matter.  Since the hardware doesn't reorder, you can take some shortcuts.

Both of the excerpts below are correct, but they're targeting a different audience.


P.S. I do think there are a few statements in the cookbook that are in need of an update.  The ppc and pa-risc situations are more complex than what's stated there.  (The PA_RISC recipe works for actual hardware, but I think the emulator on Itanium follows the rules inthe manual, which allow more reordering.  For PPC, I think the recipes for sequentially consistent operations in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html also apply to Java volatiles and are more accurate.)

From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of raghuram nidagal
Sent: Tuesday, December 08, 2009 6:12 AM
To: concurrency-interest at cs.oswego.edu
Subject: [concurrency-interest] out of order execution on uniprocessor

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/f56f5590/attachment.html>

More information about the Concurrency-interest mailing list