[cpp-threads] More niggles on the strawman proposal

[Nick Maclaren]

Here are some more points that need addressing in the strawman model,
that I have discovered when reading through the C++ standard.


My Objects Diatribe
-------------------

Upon studying it, C++ seems to have eliminated (or not introduced) all
of the worst problems.  My reading of C++ is that basic actions take
place on most derived types, and that most (or all) of the ghastliest
punning allowed by C is forbidden in C++.  There are only three issues
that I can't resolve.

The first is that I can't find where it specifies when the array to
pointer conversion is performed, and when it is not.  By experiment, it
seems to be done for all function arguments and not much else, though I
have failed to locate the wording.

Another aspect of this is that there is the same fundamental ambiguity
with any function that is polymorphic and can take array arguments, but
I can't find any of them.  Encapsulated classes do not, of course, have
the same problems.

The second is the issue to do with padding bytes in structure and union
members (because they are POD aggregates).  For example, is the
following permitted?

    union (int a[2]; int b;}

Thread 1:  a[1] = 0;
Thread 2;  b = 1;

This isn't introduced by threading, of course, because it also shows up
in "(a[1] = 0)+(b = 1)", but it will be more important in threaded
programs.  It needs clarifying, unless I have simply failed to find the
reference.

The last is the library, which I shall add something else on.


Storage Deallocation
--------------------

As in C, deallocating an object makes every pointer to that object
undefined, so that will need to be included in the relevant side-effects
as a hidden, asynchronous memory operation.  It will need a little care,
as an action in thread A can cause a object accessible only from thread
B (or even one accessible only from the library!) to be updated.


Initialization, Constructors and Copying of Aggregates
------------------------------------------------------

    1) C++ makes a definition visible before it is initialised (3.3.1)
and forbids access to its members only for const-qualified objects
(8.5).  In fact, there is an implication that constructors with
side-effects are called sequentially in sub-object order.

Threading makes the sequencing more visible than it is in a serial
program, including in cases like:

    int n = ...;
    int a[5] = {1,2,n,4,5};

Does C++ require the sub-objects to be initialised, copied etc. in
order?  That is how I read it, and will assume it, but it then brings in
the question of what the occurs-before constraints are, especially when
doing such things on volatile (or __asynch volatile) sub-objects.

I don't see this as being a major difficulty, but I do see it as
impacting performance.




Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679