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

[gpriv@axonx.com]

On Mar 13, 5:40 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> 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

OK, your point well taken, so it is up to compiler vendors to
guarantee volatility under MT.   Does it mean that original purpose of
volatile ma not always hold either?

G.