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!s19g2000prg.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 09:10:38 -0700 (PDT) Organization: http://groups.google.com Message-ID: 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> <2c2989ba-a109-40d6-b0a3-f91d94a2d291@a1g2000hsb.googlegroups.com> <9e12a297-599c-48e5-a5f9-5d6dee70e8dc@59g2000hsb.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 1205424638 25560 127.0.0.1 (13 Mar 2008 16:10:38 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 13 Mar 2008 16:10:38 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: s19g2000prg.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:20347 Date: 2008-03-13T09:10:38-07:00 List-Id: 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