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

[Maciej Sobczak <see.my.homepage@gmail.com>]

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