Re: Robert Dewar's great article about the Strengths of Ada over other langauges in multiprocessing!

[gpriv@axonx.com]

On Mar 12, 12:28 pm, Maciej Sobczak <see.my.homep...@gmail.com> 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