Re: WaitForSingleObject() will not deadlock

On Tue, 03 Jul 2007 13:53:09 -0400 Joseph M. Newcomer <newcomer@xxxxxxxxxxxx> wrote:
It seems that "memory visibility" has something to do with making
sure that results are in memory. I would have thought this would
have been more commonly referred to as the "cache coherency"
problem.

They are 2 different problems, but because x86 is TSO, they are
equivalent for that platform.

Because of the Interlocked operation used on the x86 and
x64, all results in caches and pipes are guaranteed to be in a
consistent state throughout the entire multiprocessor cache
structure. Therefore, once you have acquired any locking object,
you are guaranteed that all processors are seeing the same memory
contents, one way or another.

That is true for all processors, but this is because acquisition of a
lock is guaranteed to issue a membar, not because of cache coherency.

Strictly speaking, shared variables should be declared 'volatile' to
ensure the compiler has not kept a copy around, and this is

Strictly speaking, this is not correct. But the MS VC definition
of volatile is different than the ISO C definition. This has been
discussed to death on comp.programming.threads. Again and again.

completely orthogonal to the concept of locking; it appears that the
Microsoft C/C++ compiler is very conservative about code motions
across functions and therefore seems less subject to this kind of
error, although the formal requirements of the C/C++ language would
dictate that the use of 'volatile' is mandatory to ensure the
compiler has not done something bad.

Not correct. volatile (the ISO C definition) does no such thing.
A mutex is sufficient to guarantee visibility, and the compiler
is guaranteed not to reorder code around locking operations.

-frank
.

Relevant Pages

  • Re: C#, Threads, Events, and DataGrids/DataSets
    ... JIT compiler just compiles IL to x86 (or whatever platform it is developed ... optimization theory if you are interesting). ... then volatile could be important to guarantee that all memory writes ...
    (microsoft.public.dotnet.general)
  • Re: WaitForSingleObject() will not deadlock
    ... Even though the assignment of value 2 is guaranteed ... compiler's guarantee), without the specific guarantee from the thread ... the *compiler* does not guarantee this. ... Any data written to memory after the new thread is ...
    (microsoft.public.vc.mfc)
  • Re: shared memory between processes
    ... POSIX, for example, states several conditions under which memory visiblity ... and not one of them uses or requires 'volatile'. ... mechanisms already guarantee thread safety.) ... compiler no knowledge of the functions, thus the compiler must assume they ...
    (comp.os.linux.development.system)
  • Re: Xilinx Dual processor design
    ... Is it possible to port an OS that uses this dual-core system. ... That depends on your operating system. ... cache coherency so a system with physically shared memory can't use the ... If you have to use external memory it will kill ...
    (comp.arch.fpga)
  • Re: Exploiting Dual Cores with Py_NewInterpreters separated GIL ?
    ... read-modify-write operaitons. ... interlocking to prevent two cpu's from updating the same memory ... is cached in the processor that is performing the LOCK operation ... cache coherency mechanism to insure that the operation is carried ...
    (comp.lang.python)
Loading