Re: Redesigned thread class

From: williamkempf_at_[hidden]
Date: 2001-08-17 17:11:14

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 04:28 PM 8/17/2001, William Kempf wrote:
> 
>  >There was some confusion with the wording of my redesigned 
semantics for
>  >thread::join().  I've modified thread.html (attached) to try and 
describe 
> 
>  >the total semantics in a more precise format.  Hopefully this 
will help 
> in
>  >discussing the actual proposed changes to the semantics.
> 
> Nits:

OK, I'll take note of these and make corrections if this is the 
design we go with.  From what I see here though, it's mostly 
structural changes to the text and the intent has gotten across.  
Since it didn't the first time around we hopefully now have something 
with which to really focus the discussion on.

> The two constructor "Notes" should be "Postconditions".

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.  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 :).
 
> The intro should state that a thread has an associated state which 
is 
> either "joinable" or "non-joinable".

Agreed.
 
> The postcondition for join() should say "*this is non-joinable."  
Ditto the 
> default constructor.

Ahhh... slight grammar change.  Took me a while to get this one.  OK.
 
> The comparison operator Requires state should be "non-terminated" 
rather 
> than "running", since "running" would exclude "ready" and "blocked".

Yep.  Good catch.

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?

Bill Kempf