"Andrew Schetinin" <ascheti
...@gmail.com> wrote in message
...
> Chris Thomasson wrote:
>> You need to be sure that the "operations" effects on shared memory are
>> visible, before the updates to the "4-byte value" become visible... You
>> would use a memory barrier instruction (e.g., membar
>> #StoreLoad|#StoreStore)
>> after the operations. Of course, when a crash occurs you might not be so
>> be
>> sure that the membar instruction was even executed...
> Agree with you on memory/compiler barriers. As David said, mutex (and
> most of other synchronization primitives) enforce memory barrier,
> that's for sure. But it does not necessary enforce the compiler
> optimization barrier (which may also reorder writes). In most compilers
> there are intristic functions which enforce compiler and/or memory
> barriers. Well, anyway a combination is necessary, to ensure that the
> "state consistent" flag is updated last, after everything else is
> stored to the memory, and neither CPU nor optimizer reorder this flag
> write. Repeating the pseudo-code provided by one of you earlier:
[...]
http://groups.google.com/group/comp.programming.threads/msg/423df394a...
http://groups.google.com/group/comp.programming.threads/browse_frm/th...
(read whole thread, if you haven't already)
External assembled functions usually inhibits code motion... However, with
the advent of link-time optimizations, this may not always hold true...
Luckily, most compilers have decorations that can prevent this kind of
optimization. Sun C compiler allows one to decorate thier critical function
declarations with a pragma that tells the compiler not to optimize... MS
compiler has pragma that allows one to adjust the optimization level... ect.
IMHO, I would advise you to externally assemble and decorate your critical
function declarations with stuff that prevents link-time optimization, for
this specific function.
FWIW, GCC and MS have compiler optimization barrier functionality. I can't
remember the GCC stuff you need to use right now... I would investigate...
decorating a dummy GCC inline asm with __volatile and "memory" should act as
a compiler barrier. Humm...
On MS, calls to Interlocked API behave as a memory barrier, and the volatile
keyword in the Interlocked API block compiler optimization... However, I am
not too sure to totally trust this behavior... I still use external assembly
on MS platforms...
I know that what I do works fine for me, but you may find it difficult or
nearly impossible to create a strictly C compiler based solution... You will
probably be forces to drop down into assembly to actually get at the memory
barrier instructions.
I think the support for this stuff is going to get better over time... MS's
new compilers seem to be able to handle a DCL pattern:
http://groups.google.com/group/comp.programming.threads/msg/a369a6e49...
(look for part on MS DCL, toward middle of msg)
In the near future, it might be a very bad business decision for a compiler
vendor to not support some sort of memory barrier and compiler barrier
functionality throughout their application suites... I hope this is not
wishful thinking!
:O
