Re: [boost] [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today

Subject: Re: [boost] [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today
From: David Abrahams (dave_at_[hidden])
Date: 2008-12-25 11:33:31

on Tue Dec 23 2008, "Thomas Klimpel" <Thomas.Klimpel-AT-synopsys.com> wrote:

> Mika Heiskanen wrote:
>> David Abrahams wrote:
>> > I suggest reading through my posts in
>> >
> http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/80083ac31a1188da
>> > which give the arguments in detail.
>> 
>> Thank you for the link, I read the thread from start to finish.
>> It was not clear to me at the end that any agreement was
>> actually reached, in particular with respect to terminology.
>
> I also read the thread from start to finish. About halfway through the
> thread, I suddenly could follow the arguments given by David Abrahams,
> and he seems to be right. But now std::logic_error suddenly seems to
> make no sense any longer. Is this a valid conclusion from reading that
> thread?

IMO std::logic_error never made much sense for C++.

> Then I reviewed my past issues with using exceptions in the light of
> this new insight. My worst issues with exceptions occured in
> connection with OpenMP and MPI. Because I used exceptions as a way to
> report errors to the user, I wanted them to propagate upwards out of
> the parallel regions. But because the exceptions don't occur
> synchronous in all workers, this just messed up the control flow. And
> neither OpenMP nor MPI try to help the programmer with the task of
> synchronising exceptions and propagating them upwards. However, as
> soon as I issue exceptions only in exceptional circumstances, 

"in exceptional circumstances" has a nice ring to it, but it doesn't
mean very much in actuality.  I suggest you phrase your criterion moree
precisely so you know what you've actually discovered.

My criterion is, "issue an exception when a function cannot meet its
postcondition."

> the whole mess becomes much more managable again. So a manageable
> solution would be to handle "valid" user errors before entering the
> parallel sections of the programm, handle the few remaining "valid"
> exceptions (like out of memory conditions) by explicit communication
> between the workers, and don't try to recover from "logic errors"
> inside the parallel sections. 

Don't try to recover from logic errors, period, unless you have some
kind of "state firewall" like a process boundary that allows you to be
very sure that the rest of the system is OK.  In the case of MPI, I
even a process boundary might not be enough.

> This may force me to structure my (parallel) algorithms such that they
> have explicit resource allocation phases (during which no
> communication occurs, but exceptions are allowed), and running phases
> (during which no exceptions are allowed, but communication may
> occur). 

I haven't thought about this very much in the context of MPI, but I've
been doing some MPI programming myself recently, and IIUC it's important
for all the processes to be following roughly the same code path.  So if
you get an exception in one process but not the others, it could be easy
to confuse your parallel programs unless you do something to account for
the problem.

>> Sorry if I am being a nuisance. I thought I had already understood
>> the terminology, but reading the thread you mentioned made it a fuzzy
>> again.
>
> Sorry for misusing this thread. But reading through the above thread
> took me quite some time (yet the new insight was worth it), so now I'm
> eager to get some answers to the questions and thoughts that this
> thread induced.

Well, this is a good point; the whole thing is a bit off-topic for
Boost, unless we make it about how Boost.MPI might better support
exception handling.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com