Re: Robert Dewar's great article about the Strengths of Ada over other langauges in multiprocessing!

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 13 Mar, 00:54, gp...@axonx.com wrote:

> You are replying on posts without reading them carefully.  The issue
> is covered in the thread below:
>
> http://www.codeguru.com/forum/archive/index.php/t-442321.html

Unfortunately, most of the participants have no idea about the subject
(they even admit it), so their discussion is not a good authority.
The only exception there is Paul McKenzie, who actually claimed
clearly that *volatile has nothing to do with threads*.

There is a link to Microsoft documentation with example. This can be
treated as an authoritative source of information related to Microsoft
compilers *only* (and I have doubts even about this). Since the C++
standard does not define the semantics of volatile in the presence of
multiple threads, then any guarantee given by Microsoft should be
treated only as *language extension*. In particular, the same code
example will not work with other compiler.

To be more exact, if Microsoft claims that their example works with
their compiler, it means that references to volatile provide the
release-acquire memory consistency, which in turn means that they
involve memory barries. This is surprising, but let's check the
assembly output from their compiler...

OK, I've checked it with Visual Studio 2005 (I don't have access to
anything newer).
The generated code does *not* involve memory barriers. It will not
work.

A simpler example can explain the problem.
Consider the following two variables:

bool A = false;  // can be as well volatile
bool B = false;  // can be as well volatile

and two threads:

// Thread1:
A = true;
B = true;

// Thread2:
if (B)
{
    assert(A);
}

*From the point of view* of Thread1, only the following states are
visible, as times goes on downwards:

time 1:   A == false && B == false
time 2:   A == true  && B == false
time 3:   A == true  && B == true

In other words, from the point of view of Thread1, the following
situation:

A == false && B == true

can *never* happen, because the order of writes just makes it
impossible. In other words, the condition and assertion from Thread2
would be correct if executed in Thread1.

The problem is that Thread2 can see something different and there the
assertion can fail. This can happen for two reasons:

1. If you write something to memory, you only instruct the CPU that
you *want* something to be stored. It will do it - but not necessarily
immediately and it can actually happen *some time later*.
The problem is that if you store two values (separate store
instructions), the CPU does not know that they are related - and can
stored them physically in different order. The compiler has no control
over it! It is the hardware that can reorder the writes to memory.

2. If you read something from memory, you can actually read something
that is already in the cache - the value can be there already and
*earlier*.

Both these mechanisms can make Thread2 see different order of
modifications than that perceived by Thread1.
Again, the compiler has no control over it. It is all in hardware.

This is also a reason for why the Double-Check Locking Pattern does
not work. Please read this:

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

It describes the problem for Java, but mentions the same ordering
issues.

Don't use volatile for multithreading. It does not work.

Note: Ada gives guarantees for proper ordering for volatile objects.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com