[cpp-threads] RE: "Agenda" for august 23-25 concurrency meeting

[Nick Maclaren]

Herb Sutter <hsutter at microsoft.com> wrote:
>
> Thanks, Nick. In your latest below, I'm confused by the "of kind X" and
> "two different kinds of object" parts. Can you clarify? Transitivity in
> the examples shown earlier have to hold even when x and y are of
> different types -- or is this not what you meant?

No.  The problem is that we are running out of names - the obvious one
is "class", but that is confusing :-(

What I mean is atomic versus normal, or IEEE 754 flags versus memory
values, or file state versus memory, or ....  This also occurs if we
allow targetted acquire/release, as some designs have and some people
have proposed - e.g. lock(release=(x,y,z)) releases only x, y and z.

The trouble is that we CAN'T ignore such problems, as we already have
them with atomic and will not practically be able to avoid them with
IEEE 754 flags (if C++ supports them), signal states (mainly POSIX's
business, but C/C++ are involved), file state and perhaps others.
All of them necessarily use slightly different synchronisation
primitives and/or rules.

We CAN say that they need to have similar semantics and bind them to
the memory model, but the use of different primitives implies that
they may have a separate transitivity relation to ordinary memory.

But I am definitely NOT proposing to introduce a C99 "effective type"
into this arena.  In my "kind of", all normal memory is one kind,
irrespective of type, storage class, etc. etc.


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