Boehm, Hans wrote:
David -
If I understand this correctly, you added a sync instruction to most of
the __sync implementations on MIPS,
Correct. These primitives are new in GCC-4.3 for MIPS. My first
attempt was not entirely successful. I hope the revised version yields
better results.
largely because we don't understand
what the memory ordering rules actually are?
It is not purely due to laziness on my part, although I don't discount
this totally. There are so many different MIPS implementations with
differing behavior (some lacking sequential memory ordering) that the
only safe thing to do in the general case is to assume that 'sync' is
required as a memory barrier *and* after the atomic ll/sc loops.
I would guess this
involves a significant performance hit? (On other architectures, fences
tend to be between 10 and 200 cycles, best case. I haven't checked on
MIPS.)
Again, it depends on the MIPS implementation.
This may well be the best we can do, but it doesn't strike me as good.
It's also a problem for the C++ memory model work.
If it ends up being anything like the Java memory model, the MIPS
implementation will likely need to emit 'sync' instructions with
accesses to volatile variables.
If my understanding is correct, and you don't mind, I would like to
relay this to the MIPS architects. It might motivate them to document
some things sooner rather than later.
That is fine with me.
Was this checked in?
It was, thus the commit message in the PR.
David Daney
