Re: how to ensure other threads load new value from memory

David Schwartz <davids@xxxxxxxxxxxxx> schrieb:

On Sep 12, 6:53 am, "Dmitriy V'jukov" <dvyu...@xxxxxxxxx> wrote:
On Sep 12, 5:41 pm, David Schwartz <dav...@xxxxxxxxxxxxx> wrote:

On Sep 12, 6:32 am, Markus <philipj...@xxxxxx> wrote:

If the compiler for some reason can prove that the synchronization ca
nnot affect
buffer[] (perhaps because it is done with simple inline assembly or b
y compiler
intrinsics), I see no reason why it should be obliged to consider the
new contents of buffer!

If the compiler can prove something that is false, then it is broken.

If mutex is implemented is such a way that compiler can prove that it
cannot affect something which it actually affects than mutex
implementation is broken.

And this is why, as compilers get smarter, it may become necessary to
coordinate the design of synchronization primitives with the design of
the compiler. In the case of GCC, the 'volatile' keyword is overloaded
for this purpose. Note that this is *not* the 'volatile' specified in
the C standard, but totally different semantics implemented with the
same keyword. (Also, named invalidations are used.)

For example, from the Linux kernel header files:

static __always_inline void __raw_spin_unlock(raw_spinlock_t *lock)
{
asm volatile(UNLOCK_LOCK_PREFIX "incb %0"
: "+m" (lock->slock)
:
: "memory", "cc");
}

Note the 'volatile' which tells the compiler that it must not try to
understand what this code does or try to move it. Note also the
"memory", which is a named invalidation (it says 'assume memory may
have changed curing this call').

Now you might say "why can't the compiler look inside the assembly
code and see that only the spinlock is affected, so it can assume no
other memory addresses have changed? And the answer is -- because we
specifically told it that it could not do that.

DS

Thanks for your answer, David!

Did I get that correct: the C programming standard is not sufficient to
guarantee multi-threaded programs to work. Like OpenMP changes the semantics
of a parallel block and adds some consistency model, it is something
necessary beyond the programming standard to make a compiler able creating
"threadable" code.

Regards,
Markus

.

Relevant Pages

  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... that later locks the same mutex. ... standardized multithreading library designed to run efficiently on existing ... A C compiler is not required to do this, and it can still be a conforming C ...
    (microsoft.public.vc.mfc)
  • Re: Is C99 the final C? (some suggestions)
    ... >> of the reasons why that algorithm is worthless. ... I agree with Paul that this is a very basic and very obvious fact ... kind of mutex to block out one of the threads while the other one ... I don't expect the compiler to do anything with this information. ...
    (comp.lang.c)
  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... data written after the mutex is ... standardized multithreading library designed to run efficiently on existing ... A C compiler is not required to do this, and it can still be a conforming C ...
    (microsoft.public.vc.mfc)
  • Mutex debug lock failure [was Re: Bad gcc-4.1.0 leads to Power4 crashes... and power5 too, actua
    ... Do you have mutex debugging turned on? ... It doesn't seem to be a compiler bug. ... r3 is struct mutex, which is ...
    (Linux-Kernel)
  • Re: How to properly initialize shared memory on Unix?
    ... As David said, mutex (and ... most of other synchronization primitives) enforce memory barrier, ... But it does not necessary enforce the compiler ...
    (comp.programming.threads)
Loading