[boost] Threads Rationale

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-16 17:19:55

Aside from editorial changes which I'll post as a patch set:

The term "concept" is overused in this document, where "primitive",
"construct", or "object" would be more appropriate.

The rationale for the Lock object is somewhat roundabout. The second
paragraph begins:

  "A lock object is not a synchronization primitive"

But you've never defined "synchronization primitive", so this is not
meaningful. The crux of the issue is buried in the least-emphasized
part of the paragraph (the middle): 

   "instances of a lock object are only going to be created, at least
    in theory, within block scope and won't be shared between
    threads"

[what's with '? I doubt that's legal, and the job could be done by
"'" just as well, couldn't it?]

But anyway, I'll attempt a rewording in my patch set.

In the sequence of usage comparisons between thread_ref and
noncopyable thread object, it's unclear in some cases which is
which. A side-by-side table with descriptive headings would be easier.

-- 
                    David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html