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!news1.google.com!postnews.google.com!f63g2000hsf.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: Wed, 12 Mar 2008 16:54:52 -0700 (PDT) Organization: http://groups.google.com Message-ID: <44104211-afd5-4cf7-8467-90471d4afd1b@f63g2000hsf.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> NNTP-Posting-Host: 69.250.188.114 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1205366093 21497 127.0.0.1 (12 Mar 2008 23:54:53 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 12 Mar 2008 23:54:53 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: f63g2000hsf.googlegroups.com; posting-host=69.250.188.114; posting-account=YaY8rAoAAAAAnFXOECY3BGVJsrvFJCgy User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; 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:20329 Date: 2008-03-12T16:54:52-07:00 List-Id: On Mar 12, 12:28 pm, Maciej Sobczak wrote: > 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 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 Please read carefully before throwing back your expertise that I am sure is quite adequate. Otherwise it is quite hard to maintain meaningful discussion. Cheers, George