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!i12g2000prf.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: Wed, 12 Mar 2008 09:28:42 -0700 (PDT) Organization: http://groups.google.com Message-ID: <33557da4-e4ba-4c75-9a55-4b7eb5fdad3b@i12g2000prf.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> NNTP-Posting-Host: 128.141.45.252 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1205339322 10474 127.0.0.1 (12 Mar 2008 16:28:42 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 12 Mar 2008 16:28:42 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i12g2000prf.googlegroups.com; posting-host=128.141.45.252; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; 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:20321 Date: 2008-03-12T09:28:42-07:00 List-Id: On 12 Mar, 15:41, gp...@axonx.com wrote: > > In C++ destructor can be inlined *always*, unless the object is > > deleted via pointer to base. In other words, objects with automatic or > > static storage duration (local, static and global) objects can have > > inlined destructors - no matter whether it is virtual or not. > > Yes if compiler can make that determination at compile time. Certainly the compiler knows at compile time whether the object is a local variable, static or global. This property does not depend on anything at run-time. Example: class MyClass {/* ... */}; void swallow(MyClass * p) { delete p; } MyClass G; // global (static in disguise) void foo() { static MyClass S; // static MyClass L; // local MyClass * D = new MyClass; // dynamic swallow(D); } Objects G, S and L can have destructors inlined. This is known at compile time. Object denoted by pointer D will most likely have the destructor called virtually (because function swallow cannot assume anything about its dynamic type), unless the compiler+linker is smart enough to do some wider optimizations. In the most extreme case (global linker optimization), all calls can be resolved statically. > Definition of volatile: [...] I don't know where you got that definition from, but certainly not from the standard - and as such it is incorrect. > Consider the multi-core execution of two concurrent threads. One will > modify a variable, another will read. One will keep the variable in > the register, another will reload it from the memory. Volatile will > force flushing to the memory. Otherwise thread 2 will read erroneous > data. No. Your perception of what and where is the "memory" is completely different from that of CPU(s). The volatile keyword can, at best, force the compiler to use some "memory address" for access. The problem is that between "memory address" and "physical memory" there is a long chain of funny things like asynchronous memory writer in CPU and a few layers of cache with complicated prefetch functionality. The cache is transparent so can be ignored, but the memory writer module and prefetch work *asynchronously* and this means that when you "read" and "write" your variables, you really don't read and write what you think - or rather not *when* you think. This happens out of the compiler's control (it's hardware), so "volatile" cannot help you - you can as well write it in assembly and still have the same problem. You need memory barrier to ensure visibility between CPUs and volatile does not provide it (unless you have some funny compiler). To actually get the barrier, you have to either apply it by hand or use dedicated system services that do it for you (mutexes, etc.). Now, the best part - once you do it, volatile give you nothing. No, the best part is this: volatile not only gives you nothing, it actually *slows the program down*, because it prevents the compiler from applying some obvious optimizations when the given object is used many times within the critical section. You don't want to slow your program down, do you? :-) And last but not least - have you tried to use volatile with some C++ classes, like string, vector, map, etc.? Try it. It will not even compile, but certainly it is possible to use these classes with many threads. Short version: don't use volatile for multithreading. It's not the correct tool to do the job. The correct ones are membars and these are part of dedicated system services. Use them. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com