Re: [boost] Threads & Exceptions...

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-13 14:47:48

From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
> It seems like everyone has lost the original direction of the original
> conversation. I like to wax philosophically just as much as the next girl
or
> guy, but arguing over interpretation of the standard is not very useful.
It
> is clear that we are working beyond the bounds of the standard, we will
all
> have to except that some rules will have to be bent, or just do not apply.
> (Some of us probably feel like all of the work that goes into threading
will
> get proposed to the standard one day, but C++ with multiple entry-points
is
> likely too different for some simple tuning of the existing standard, and
> will likely require a proposal to an entirely different language.)

Uhmm... to some degree I agree... but where the rules are bent we'd better
follow the rules of the underlying thread implementation instead.

> It's clear to me that if one needs the return value of a thread, they will
> certainly call join. If the thread has no return type, the default
behavior
> is to terminate on exceptions, which everyone agrees on.

*shakes head*  No, everyoen does not agree on that.  This is an
over-simplification of the issue, and fails to address a large number of
concerns.

> It is not clear to me how 'polling for exceptions' introduces race
> conditions, or how/why anyone would be 'polling for exceptions'. The
> exceptions are checked for the user after the call to the implementation's
> join (), so that is a non-issue.

That's a poll.  And it's a poll that works only at the end of a thread's
lifetime.  Unless the thread is an autonomous task, i.e. it doesn't use any
shared resources, then polling doesn't help in insuring thread/exception
safety while the thread is still accessing the shared resources.

> If there is a possibility to by-pass join
> and check for exceptions directly in the public interface, I can't see how
> this would possibly introduce any 'race-condition' either in a well
designed
> thread class--certainly the designers of a thread class understand how to
> make a method that accesses and attribute thread-safe. In any case, it
> doesn't make sense to poll for exceptions because they do not exist until
a
> call to join would pass through successfully anyway.

It produces a race condition because this is what you get:

* thread safe check to see if the thread has not terminated.
* code that access the shared resources

Between the two operations you have a race condition where in the thread
could become terminated.

> I don't think anyone can argue against the policies themselves, which
allow
> the end user to mutate the behavior of the thread to do whatever they
> need--certainly as designers, we can't preclude unforeseeable usage. I can
> see room for argument about which policies should be promoted by boost
> itself, but again, everyone can see by our conversations alone that a
> terminating policy and an exception throwing policy are in fact useful and
> needed.

No, I'm not sure that this is all that clear, even still.

Bill Kempf