Help: Unwinding the C++ stack...throw, longjmp & threads

[craig@jcb-sc.com]

>Craig Burley, writing in the async interrupts debate.
>
>> Further, few people who say things like "lost in the noise" understand
>> the fine distinctions between *types* of noise.  In this case, I hope
>> you don't consider synchronous bugs (bugs triggered by normal,
>> straightline code) as in any way similar to asynchronous bugs.
>> Excellent programmers can do a great job squashing the former
>> kind -- very few understand how to even begin setting up a test
>> bed that finds the latter (I could only *begin* to guess at that,
>> myself, offhand).
>
>You use the techniques hardware engineers do.  Digital oscilloscopes
>to capture bus transactions; traces to capture every instruction executed,
>stuff like that.  I've been there.

Me, too, but I consider that quite inadequate in larger-scale systems,
such as the huge software systems we tend to build because it's so much
easier than building them out of silicon.  E.g. the GCC testsuite
architecture would surely be inadequate if GCC was heavily into async
stuff (built out of threads, used shared memory, whatever) -- for example,
there'd need to be ways to test known hot-spots across a range of timings
at which various async exceptions would be thrown at them.  (Linux has
this, of course -- the testsuite being a few million users on a wide
variety of platforms.  :)

>> It's painful work getting this stuff right -- I remember spending *hours*
>> just verifying that a particular shared-resource management scheme,
>> implementing very simple primitives, was bullet-proof.
>
>Formal verification techniques have been used successfully here; for
>instance, pretty much everyone doing multiprocessor hardware now does
>formal verification for their cache coherency protocol.  But these
>techniques need some skill to use.

Indeed, and, back in 1980 or so, when I was doing that particular
project, we didn't have much in the way of software assists (and,
stunningly to me looking back on it, I had basically zero experience
with formal verification techniques anyway, though, it could be the
case that I basically made them up as I went along, sufficient to
meet the needs of that particular task).

>I think that you're lumping two things together here: synchronous
>exceptions are just branches, with a limited number of sources and
>destinations.  It's async exceptions that make life horrific.

Indeed, though I am suspicious that even sync exceptions will be to
the next decade what GOTOs were to the '70s, for roughly the same
reasons.  ;-)

I have much to learn about what is exactly going on, but, having
applied my budding "linguistic sensitivities" to what I already do
know about synchronous exceptions, I don't see any clear winner of
an answer to the problem of making sure people reading a chunk of
code don't misunderstand what is going on.  Eliminate sync exceptions
from a language, and code that needs it might mislead programmers
into thinking some paths are more important, or likely to be taken,
than otherwise -- perhaps confusing them sufficiently to misunderstand
the normal paths.  Leave sync exceptions in, and, unless they're
somehow linguistically restricted, readers might not see important
potential branches -- which might be highly dependent on implementation-
chosen types for variables, for example.  (I.e. they're not lots
better than `volatile'.  Sure, in the context of C++, such linguistic
problems might indeed be "lost in the noise", but that's a *lot* of noise,
and I'm thinking in terms of the next several billion programmers to
help write free software, not the few hundred or thousand that, today,
can actually write C++ code that works *and* is readable.  I'm not
even sure I could supply the next ten thousand Fortran programmers with a
proper language design that'd keep them from writing hard-to-debug code,
though, since, so far, all I've gained much confidence about is what
sorts of things *don't* work, not what new things might.)

My best hope right now is to find some linguistic means to express sync-
exception semantics at as high a level as possible, such that they can
always be implemented as mere branches, then leave it up to optimization
to make use of underlying support for exceptions, so readers always "see"
the branches, including their relevance and importance.

Mostly, though, I expect there isn't a real clean solution there, within
the realm of the imperative programming model.  Higher-level models
presumably offer ways of escaping the mundane problems of all these
exceptions, leaving the bigger problem of assuring programmers that
their expressions will be implemented in finite time and space....

        tq vm, (burley)