[cpp-threads] Re: Comments on Hans's latest strawman proposal

[Nick Maclaren]

"Boehm, Hans" <hans.boehm at hp.com> wrote:
>
> Doesn't this force exceptions to be more precise than they usually are,
> e.g. prevent many kinds of loop pipelining?

No.  Precisely not.  I wrote those specifications so that they do allow
exceptions to be as imprecise as possible, subject to being even
minimally usable.  Please note that, if the user does not include any
explicit synchronisation actions, it places no constraints on the
implementation beyond the fact that exceptions must not be promoted
to before the program starts or delayed until after it finishes.

> Unless I'm misunderstanding
> things here, this is going to generate controversy here for two reasons:
> 
> 1) I suspect it's a tradeoff between optimization and usability of fp
> exceptions, and

That is true.  Without such a description, their specification will
vary in an undocumented way between implementations.  That is the
ungodly mess we have at present with POSIX threads, and it makes them
effectively unusable for tightly coupled codes :-(

> 2) I'm not sure it makes sense in the context of the C++ standard,
> without also defining some of these exceptions

Eh?  There already ARE many such exceptions defined!  1.9 para. 15, 3.6.2
para. 4 (as nasty one), 5 para. 5 and others all define such exceptions.
Yes, how they are handled is implementation-dependent, but they are
already there in the standard.

> Since it also doesn't seem to be directly related to threads, I'm not
> sure we really want to go there as part of this poroposal.

I am sorry, but it is critical.  Here are a few of the reasons:

Unless the framework and model includes them, implementors and/or The
Open Group WILL define them, incompatibly and possibly insanely, and we
shall have another POSIX threads on our hands.

There are already a lot of implementations that support such exceptions
(often in the form of signals), sometimes with specific reference to
C++.  Look at Sun ONE Studio, for example.

The IEEE 754 people are on the march again, with vendor backing, and
are going to try to get exception handling put into the mainstream
programming languages.

We really, but REALLY, do not want C99's IEEE specifications used as a
basis.  I lack the vocabulary to describe how ghastly it is.

Most experience is that the combination of exceptions and threading is
many times the problem of either on its own, unless they at least use
the same model as a basis.

> > [ PROBLEM: God help me, POSIX permits things like SIGFPE to
> > be raised in a thread other than the one where the arithmetic
> > exception occurred. ...
>
> I think that if we wanted to say anything about this, it would be to
> forbid this behavior altogether.  This kind of synchronous exception
> should be handled by the thread that generated it.  My guess is that was
> also the Posix intent, though it may not be clear.  I'm not sure that
> it's our job to fix their bugs.

I am happy with that, but I can assure you that it was not the intent.
I was working at IBM Santa Teresa at the time the "designated thread"
issue arose, and I was consulted on my views.  Luckily, semi-sanity
prevailed, and at least POSIX permitted the only respectable design.

HOWEVER, please note that not all exceptions can be raised in the thread
that caused the action triggering them.  I gave an example on another
mailing list recently, w.r.t. SIGSEGV (relevant for embedded codes):

    If the SIGSEGV is due to a bad address, then the only sane thing
    is to raise it in the thread that triggers it.

    If the SIGSEGV is due to a delayed memory failure with a write-back
    cache, or being unable to write a page to the swap device, there
    may be no record of the failing thread when the exception is raised.

Another, purely software example, is an I/O class that raises exceptions
but also supports buffering and asynchronous I/O.  A failure may occur
when writing out a buffer comprised of data from many threads, possibly
after all of them have terminated.


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