Daniel Miller wrote:
[...]
>    references to the threads module in RogueWave's SourcePro Core:
>    http://www.roguewave.com/support/docs/SourcePro/threadsref/index.cfm
>    http://www.roguewave.com/support/docs/SourcePro/threadspl/index.cfm
>    http://www.roguewave.com/support/docs/SourcePro/threadsug/index.cfm

Nice pictures... ;-)

>
>    references to POSIX concurrency concepts:
>    http://www.opengroup.org/onlinepubs/007904975/toc.htm
>    especially
>    http://www.opengroup.org/onlinepubs/007904975/functions/contents.html

http://www.opengroup.org/publications/mem-online/c950/c950.pdf
http://www.opengroup.org/publications/mem-online/c951/c951.pdf
http://www.opengroup.org/publications/mem-online/c952/c952.pdf
http://www.opengroup.org/publications/mem-online/c953/c953.pdf
http://www.opengroup.org/publications/mem-online/c610/c610.pdf

Registration and free membership to get access:

http://www.opengroup.org/austin

>    references to ACE's concurrency classes:
>    http://www.cs.wustl.edu/~schmidt/PDF/ACE-concurrency.pdf

http://www.cs.wustl.edu/~luther/PACE/PACE-abstract.html

"PACE was born to abstract support for current and additional
 non-POSIX platforms away from ACE, thus, becoming an API for
 ACE developers to write to."

http://www.cs.wustl.edu/~luther/PACE/Introduction/begin.html

"This idea quickly developed into the broader concept
 that the POSIX interface library could actually replace
 the ACE_OS layer in the feature laden ACE framework
 library and has since grown or will grow to include
 platforms such as Win32 and VXWorks (which lack true
 POSIX compliance)."

"As you can see, this creates a benefit for ACE,
 namely, PosixACE (PACE) becomes a formal starting
 point to begin reducing the complexity and interdependence
 problems that had creeped into ACE over the past 5 years."

<wink>! <wink>!! <wink>!!!

A few more "random" refs:

http://groups.google.com/groups?as_umsgid=200004102031.PAA03519%40ace.cs.wustl.edu
http://groups.google.com/groups?as_umsgid=200004111414.JAA29600%40tango.cs.wustl.edu
http://groups.google.com/groups?as_umsgid=200004111538.LAA02883%40janis.gtri.gatech.edu
http://groups.google.com/groups?as_umsgid=200004111844.NAA17044%40ace.cs.wustl.edu
http://groups.google.com/groups?as_umsgid=15006.51001.969280.276220%40charanga.cs.wustl.edu

regards,
alexander.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

If you are looking for some prior artwork on threading please
also look at the Ada95 standard. One of the pleasant features
of that standard is that it is freely available on the web.
You can download a copy from www.adapower.com. You can also
get a copy by downloading the GNAT Ada compiler. GNAT is
in the GNU toolchain.

Ada first incorporated concurrency into its syntax in 1983.
The 1995 standard fixed problems with the 1983 concurrency
model and added some very useful features. A summary of the
Ada concurrency features includes:

1) threads (Ada calls them tasks)
2) high-efficiency interthread synchronization for uniprocessors
    and multiprocessors
3) high-efficiency interthread asynchronous communication
    (ordered or not, as defined by the application programmer)
    for uniprocessors and multiprocessors
4) robust thread termination facilities and rules
5) threaded signal handling


Jim Rogers

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

   In prior postings to this newsgroup numerous people have criticized the
current state of Boost.Threads as not being what they would like to see become a
C++0x standard library modeling
   1) threads,
   2) high-efficiency interthread synchronization for uniprocessors &
multiprocessors,
   3) high-efficiency interprocess (same processor, shared memory)
synchronization for uniprocessors & multiprocessors,
   4) high-efficiency interthread asynchronous ordered communication (a.k.a.,
message-queues in most RTOSes), and
   5) high-efficiency interprocess (same processor, shared memory) asynchronous
ordered communication.

   If the current state of Boost.Threads is not what some people envision, what
is a good goal/vision for a C++0x concurrency library?

   Exhaustive lists of features & detail is encouraged.  References to
already-existing statements (brief or lengthy) on this topic are encouraged.  I
intend this thread to be a brainstorming activity, since some of us are
concerned about the current state & direction of Boost.Threads.  References to
prior art examples are encouraged.

   I intend both the brand-name-people of C++ and the grassroots-people to
express their desired-state for a concurrency library for C++0x.

   There is a chance that Boost.Threads will never look like the rich
multithread/concurrency support that we see 1) in the threads module of
RogueWave's SourcePro Core nor 2) in the MT aspects of ACE nor 3) in most RTOSes
nor 4) in POSIX, despite three of these four prior arts emphasizing portability
& broad-audience/general-purpose usefulness.  I have worked for nearly a decade
in using C++ in real-time multithreaded embedded systems (telecom equipment
industry).  As an individual professional in the industry which could make use
of standardized MT (and from which C++ sprung in its early days), the current
state & potential future of Boost.Threads very much disturbs me.

   references to the threads module in RogueWave's SourcePro Core:
   http://www.roguewave.com/support/docs/SourcePro/threadsref/index.cfm
   http://www.roguewave.com/support/docs/SourcePro/threadspl/index.cfm
   http://www.roguewave.com/support/docs/SourcePro/threadsug/index.cfm

   references to POSIX concurrency concepts:
   http://www.opengroup.org/onlinepubs/007904975/toc.htm
   especially
   http://www.opengroup.org/onlinepubs/007904975/functions/contents.html

   references to ACE's concurrency classes:
   http://www.cs.wustl.edu/~schmidt/PDF/ACE-concurrency.pdf

   [I apologize if this topic is addressed in one concise thread in the deep
history of this newsgroup.  In my searches so far in c.s.c++, I have only found
a phrase here or a sentence there in passing.  A reference to such a prior
in-depth series of postings on this topic---or someone's summary
WWW-page---would be part of what I am hoping to receive in reply to this posting.]

   [Any views which I express are purely my own and not those of any
collective-entity with which I may be associated.]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Daniel Miller:
>    In prior postings to this newsgroup numerous people
> have criticized the current state of Boost.Threads...

Was it numerous people? It seemed more like
one person to me ;-) Still, I thought he raised some
good points.

> ...as not
> being what they would like to see become a
> C++0x standard library modeling
>    1) threads,
>    2) high-efficiency interthread synchronization for uniprocessors &
> multiprocessors,

boost.thread already has these two.

>    3) high-efficiency interprocess (same processor, shared memory)
> synchronization for uniprocessors & multiprocessors,
>    4) high-efficiency interthread asynchronous ordered communication
(a.k.a.,
> message-queues in most RTOSes), and
>    5) high-efficiency interprocess (same processor, shared memory)
asynchronous
> ordered communication.

Well, yes to all of these. For (4) has anyone taken
a good look at asynchronous delegates in .net?

delegates are basically closures (function pointers
to member functions, pre-bound to a particular
object). You can invoke them asynchronously so
that they are non-blocking and will make the requested
call on a thread from a thread pool. The return value of
the asynchronous call is a call completion object which
you can query or wait on. I like the simplicity of this
approach. It could certainly form the basis of a
messaging system, but is simple enough for tasks
where the full messaging infrastructure is overkill.

6) Thread specific storage?

boost.thread has that as well.

>    If the current state of Boost.Threads is not what
> some people envision, what
> is a good goal/vision for a C++0x concurrency library?

I think it is a little unfair to compare the current state
of boost.thread with a final goal or vision. As I understand
it from the docs, the intent is that boost.thread will be
enhanced further over time: there is more to come.

However, brainstorming on threads is certainly a
helpful activity. I see it more in a positive light -
what can be done in future? - rather than a list of
criticisms of boost.thread.

Just posting links to long external documents isn't what
I personally want to see. In all honesty I don't have the
time to read them all (and I'm betting I'm not the only
one) so I find a brief summary, as part of the post,
very useful.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Garry Lancaster wrote:
>
> Daniel Miller:
> >    In prior postings to this newsgroup numerous people
> > have criticized the current state of Boost.Threads...
>
> Was it numerous people? It seemed more like
> one person to me ;-)

Ha ha. But NOW (counting Daniel's original post)
it seems more like *numerous*, I guess. ;-)

Also, click here:

http://groups.google.com/groups?as_q=boost.threads&as_ugroup=comp.std.c%2b%2b

Well, I don't really want to go into cycles here as
well (did it already on boost.org ;-)) repeating again
and again and again the idea "pthreads++"... just want
drop these links (related to "features"; pointing to
some relatively GOOD MS-stuff, this time ;-))

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndllpro/html/msdn_scalabil.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmsj99/html/pooling.asp
http://groups.google.com/groups?as_umsgid=c29b5e33.0202121418.26d77875%40posting.google.com

regards,
alexander.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]