Re: Redesigned thread class

From: williamkempf_at_[hidden]
Date: 2001-08-18 07:44:04

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 06:11 PM 8/17/2001, williamkempf_at_h... wrote:
> 
>  >Agreed.  This brings up some questions about when to use
>  >what "header" though.  So far we've used "Effects:" for a lot of
>  >things that it appears the standard writers would have
>  >used "Postconditions" for.
> 
> I was just looking at that in the standard last week.  The standard 
has the 
> same effects/postcondition confusion in lots of places, but I 
didn't 
> consider it worth defect reports.

I wouldn't either, but it would still be nice to have this documented 
so that future documentation can be written with confidence.

>  >  Hopefully we can work this stuff out
>  >during review, as well as provide enough guidance in this regard 
so
>  >that others can write documentation to this style with 
confidence :).
> 
> I'm not sure who developed the style, although it may have been 
Bill 
> Plauger. It takes some getting used to, but is very precise.  I've 
> switched  to it generally, and am quite happy. It would help both 
Boost and 
> the standards committee if we can document it better.

I agree totally!
 
>  >Now, do the semantics sound usable?  What are the pros/cons of 
this
>  >design compared to the original design?  Anyone strongly against 
my
>  >switching to this new design?
> 
> Others understand the nuances better than I do, but it does seem a 
bit 
> easier to grasp.
> 
> Please verify something for me.  Alexander quoted Dave Butenhof as 
saying:
> 
>  > But there were two problems. [1] There was no way to alter the
>  > initial thread of a process so that its resources would be
>  > automatically reclaimed on termination. [2] And there was this
>  > nasty problem in join; where, if the join is cancelled,
>  > which implies it didn't complete, the target thread of the
>  > join would languish forever -- another memory leak about
>  > which the program could do nothing.
> 
> Is it correct that your design does not have either of these 
problems 
> because C++ semantics take care of [1], and [2] can't happen 
because there 
> is no join cancellation?

I don't understand [1].  Seems to me that even in C an atexit() 
routine could be used to insure this.  However, it's probably a minor 
technical issue related to [2].  With [2] you've missed the context 
of the quote.  He meant that these problems occurred when they 
removed pthread_detach(), and so pthread_detach() had to be re-
added.  Boost.Threads does include "detach", via the destructor, so I 
don't think we have a problem here even when we add cancellation.
 
> I'm a bit worried about [1] in the case of a platform that had no 
native 
> threading.  Wouldn't Boost.Threads then have to do some 
initialization work 
> before starting the initial thread and some final work after the 
initial 
> thread finished?

After, yes.  We'd need an atexit() routine.  However, this routine 
can be "lazy initialized" so there's not a real need for doing 
anything prior to main().

>  But if that happened, it would seem easier to require the 
> initial thread be named something other than main (so main() could 
do the 
> startup then shutdown). That way the semantics of join() wouldn't 
have to 
> be messed with.

Now, we should make sure that I interpreted this all correctly.  
Alexander, do you see any issues here related to any of this?

Bill Kempf