[cpp-threads] Temporal models

[Nick Maclaren]

Hans has described the I/O issue correctly - we have had several
discussions on the matter.  While I agree that it is a matter to
deal with in the library, I am discussing the principle here.

What I am thinking of is examples like the following (to take an
extreme case, where 99.9% of programmers will assume what C++ does
not currently require):

Thread A:  Writes datum X to a FIFO X
           Reads datum Y from a FIFO Y in such a way as to change its
state [ that constraint is critically important, to allow optimisation ]
           Conditional on the value of Y, updates location P

Thread B:  Reads datum X from FIFO X in such a way as to change its
state [ that constraint is critically important, to allow optimisation ]
           Inspects location P
           Writes datum Y to FIFO Y

Now I assert that (except for the handful of us debating this point)
it will never even cross the mind of programmers that thread B's
inspection of location P might see the update that has not happened
yet.  As someone with considerable experience in this area, I know
that my chances of being able to even EXPLAIN that to even an average
bright programmer are less than 10%.  That is NOT good news :-(

Note that this is more about what may NOT happen than about what is
required to have happened.  Programmers are used to the concept of
updates being delayed, and not visible everywhere quite in the order
they happened - or, at least, they will be once they get a little
experience with parallelism!  But the concepts of events that have
not yet happened (or, worse, aren't going to happen!) warping back
in time is outside their mindset.

Also, note that this isn't just a library issue, but arises with all
forms of communication - semaphores, atomic operations etc.  Now,
semaphores are dealt with by making them synchronisation operations,
and (as one of my papers indicates), I believe that the I/O and other
external action problem is simple enough by requiring the library to
synchronise storage (while allowing buffering and the cancellation of
operations with no overall effect).

Unfortunately, that still leaves the very thorny issue of atomic
operations.  I think that we all agree that forcing them to synchronise
memory destroys their point, but it is very unclear how to avoid them
introducing this problem.  My belief (as I have said) is that it can
be alleviated by isolating them - but that is not the only possible
approach.


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