[concurrency-interest] out of order execution on uniprocessor
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
> 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
> 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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest