Implementation of memory ordering for volatile/unsafe accesses. This supports ordering of "Independent Reads of Independent Writes" as tested by VolatileIRIWTest of the torture test suite:

 Example: volatile x=0, y=0
  __________    __________    __________    __________
 | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |

   write(x=1)    read(x)       write(y=1)    read(y)
                 read(y)                     read(x)

 Disallowed:     x=1, y=0                    y=1, x=0

Solution: This example requires multiple-copy-atomicity. (See "A Tutorial Introduction to the ARM and POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and Peter Sewell, INRIA/Cambridge.) This is only assured by the sync instruction and if it is executed in the thread doing the load. Thus we implement volatile read as sync-load-acquire and omit the sync/MemBarVolatile after the volatile store. MemBarVolatile is implemented by sync on PPC.

This addresses a similar issue as fix "8012144: multiple SIGSEGVs fails on staxf" for taskqueue.hpp.

On PPC, the MemBarVolatile after volatile stores does in addition to the required store-load barrier a store-store barier. This is because MemBarVolatile is implemented as sync inctruction which does all four barriers in one instruction. Because of this, initialization of volatile variables is no more assured to happen before the initialized object gets visible. To assure this, we add the MemBarVolatile again at the end of constructors.

Looking at the code, we found a MemBarRelease that to us, seems too strong. We think in parse1.cpp do_exits() a MemBarStoreStore should suffice.