From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e0e1d3b3f7c994b8 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!a1g2000hsb.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Robert Dewar's great article about the Strengths of Ada over other langauges in multiprocessing! Date: Thu, 13 Mar 2008 02:40:47 -0700 (PDT) Organization: http://groups.google.com Message-ID: <2c2989ba-a109-40d6-b0a3-f91d94a2d291@a1g2000hsb.googlegroups.com> References: <13t4b2kkjem20f3@corp.supernews.com> <89af8399-94fb-42b3-909d-edf3c98d32e5@n75g2000hsh.googlegroups.com> <47D39DC8.20002@obry.net> <114f711c-9cf8-4fdb-8f11-77667afb8719@c33g2000hsd.googlegroups.com> <33557da4-e4ba-4c75-9a55-4b7eb5fdad3b@i12g2000prf.googlegroups.com> <44104211-afd5-4cf7-8467-90471d4afd1b@f63g2000hsf.googlegroups.com> NNTP-Posting-Host: 137.138.182.223 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1205401247 7328 127.0.0.1 (13 Mar 2008 09:40:47 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 13 Mar 2008 09:40:47 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: a1g2000hsb.googlegroups.com; posting-host=137.138.182.223; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20080211 Red Hat/1.5.0.12-0.10.el4 Firefox/1.5.0.12 pango-text,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20337 Date: 2008-03-13T02:40:47-07:00 List-Id: 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