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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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!x30g2000hsd.googlegroups.com!not-for-mail From: gpriv@axonx.com 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 09:16:07 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <13t4b2kkjem20f3@corp.supernews.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> <2c2989ba-a109-40d6-b0a3-f91d94a2d291@a1g2000hsb.googlegroups.com> <9e12a297-599c-48e5-a5f9-5d6dee70e8dc@59g2000hsb.googlegroups.com> NNTP-Posting-Host: 151.196.71.114 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1205424967 24511 127.0.0.1 (13 Mar 2008 16:16:07 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 13 Mar 2008 16:16:07 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: x30g2000hsd.googlegroups.com; posting-host=151.196.71.114; posting-account=YaY8rAoAAAAAnFXOECY3BGVJsrvFJCgy User-Agent: G2/1.0 X-HTTP-Via: 1.1 SPARKS X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20348 Date: 2008-03-13T09:16:07-07:00 List-Id: On Mar 13, 12:10 pm, Maciej Sobczak wrote: > On 13 Mar, 12:42, gp...@axonx.com wrote: > > > OK, your point well taken, so it is up to compiler vendors to > > guarantee volatility under MT. > > Vendors can (and should) provide you with some way to write correct MT > programs. This is an issue of normal competition on the market. > There are different ways to do it and language extension is one > possibility. If Microsoft claims that volatile works on their > compiler, it is language extension. > > On the GNU side of the world the set of tools does not involve > volatile at all. Instead you get a set of POSIX interfaces that give > necessary guarantees related to memory consistency and visibility > (actually, POSIX gives them for C only, but this isn't a problem > except for standard lawyers). > Windows, as an operating system, provides similar guarantees with > similar interfaces (for example, pthread_mutex_lock in POSIX can be > compared to EnterCriticalSection on Windows). If you have a library > that abstracts the interface differences away (like Boost.Thread), you > can write portable software without any use of volatile. You don't > need volatile, because the system interfaces already provide the > necessary memory consistency and visibility guarantees. And since it > is possible to write portable software this way, it is what I would > recommend. > > If you start using volatile relying on language extensions provided by > one particular vendor, you will not be able to easily port this > software to other platforms. > > > Does it mean that original purpose of > > volatile ma not always hold either? > > Original purpose of volatile did not relate to threads, so nothing > changes there. > To be exact (and to complete the discussion), the volatile type > specifier can be used to implement I/O, for information exchange with > signal handlers and for long jump. None of it is related to threads. > > -- > Maciej Sobczak *www.msobczak.com*www.inspirel.com So if you write to IO through volatile and later read from it, you may get the same value fetched back by "smart" CPU. G.