[cpp-threads] throw/catch and sequence points

Nick Maclaren nmm1 at cus.cam.ac.uk
Sun Jan 22 12:37:48 GMT 2006


Well, either I have seriously omitted to find the reference, or there
is a serious omission in the C++ standard :-)

1.7 paragraph 17 says that there is a sequence point after the copying
of a return value and before the execution of any expressions outside
the function, and the attached footnote makes it clear that this was
intended to apply to throw and catch.

Er, but isn't the point about throwing an exception within a function
and catching it by a handler outside that function (perhaps in a quite
different file) that the return value is NOT copied?

Now, for reasons that I can attempt to explain in ghastly detail (but
will almost certainly not make clear), this is a real problem and is
much more serious for threaded codes than for serial ones.  I have
been caught by it, badly, on some systems.

The simplest example is a function that evaluates an expression that
updates an object A while (not sequence-point separated) throwing an
exception B.  One interpretation of sequence points is that the handler
is then called in a nonce sub-tree rooted at the point the exception
is raised.  That is, actually, how a large proportion of hardware
works.

This means that there is no sequence-point ordering between the
update of A and the execution of the handler, and the programmer has
no power to introduce any.  So what happens when the handler completes?
Well, in practice, nothing special.  This is BAD news.  As far as the
standard goes, that is pretty hard to justify, but I can assure you
that it is what implementations will do.

What almost all systems do, after the problem has bit badly enough
that they realise it must be fixed, is to put a barrier somewhere
around the throw/catch (it doesn't matter where).  Unless I have
missed something critical, C++ needs to do the same.

Note that this ISN'T just relevant to hardware-raised exceptions,
but applies even to the most explicit throw/catch clauses on systems
with sufficiently loose memory ordering.

So I am right or confused?


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



More information about the cpp-threads mailing list