Re: Boost.Threads draft library submission

From: williamkempf_at_[hidden]
Date: 2001-03-19 14:26:51

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> 
> > > Yes it does, but I'm not sure I like them.  I generally follow
> > > the rule "assert the invariant".
> >
> > Others have said "assert the precondition".
> 
> The important thing is not whether an invariant or a precondition 
does not
> hold, but rather do you know who is to blame?
> 
> If you know that the caller did something wrong, say "documented 
undefined
> behavior" and do whatever you like.

This is the part that's still tricky to me, at least in this 
particular case.  The violations are user violations (almost all 
precondition violations are user violations by definition).  Here you 
say to call it undefined behavior and to do what ever I like, but 
earlier it was stated that all undefined behaviors should be 
asserted, which makes sense at a high level.  The problem is, asserts 
terminate the app and are detectable only when "turned on".  The 
original thread that started this was the checks on misuse of locks 
(which may in the future be extended to deadlock detection above and 
beyond the normal checks).  This condition can often arise from race 
situations in threaded programming so checking only when the 
assertions are turned on can result in undefined behavior that's 
never caught during debugging.  Further, it's a situation in which 
many programs can easily and safely recover from the error.  So both 
qualities of the assert _seem_ detrimental to use here.

The thread_error added as error checking for the calls to the 
underlying APIs would be much more appropriate for assertions, 
however.  This is something I'll change soon, regardless of the rest 
of this.

Bill Kempf