[concurrency-interest] out of order execution on uniprocessor

Peter Veentjer alarmnummer at gmail.com
Thu Dec 10 08:55:31 EST 2009

Some time ago I placed a blogpost about this topic:


On Tue, Dec 8, 2009 at 7:37 PM, Boehm, Hans <hans.boehm at hp.com> wrote:
> 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.
> Hans
> 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
> Hi,
> 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.
> http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#reordering
> 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.
> http://gee.cs.oswego.edu/dl/jmm/cookbook.html
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list