Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk