In article <3d85f8df.0201071439.30471dc4@posting.google.com>, Beman Dawes
wrote:

> Wil Evers <bouncer@dev.null> wrote in message
> news:<a14c77$3dv$1@news1.xs4all.nl>...
>
>>  That aside, why not discuss the feature set of a
>> future standard C++ threading library in the appropriate newsgroup for
>> C++ standardization? [followups set to comp.std.c++].
>
> Whew!  Boost's mailing list is high volume, covers a lot of Boost
> specific topics, is tightly moderated, and is aimed a very specific
> audience.  We also don't know when we start talking about a library if
> it will turn out to be of interest for standardization. Not all are.
> You wouldn't want our discussions on comp.std.c++!
>
> Also, the standards committee is going to focus on existing practice.
> Boost, and other non-committee places, are where the innovation is
> coming from this time around.

I agree that the Boost mailing lists are the primary forum for discussing
the design of the Boost libraries.  However, when a library is submitted to
the committee for their upcoming C++ Standard Library Technical Report,
this changes.  From that point on, it becomes of interest to a much wider
audience, and you should expect additional discussions in the C++
newsgroups.

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[Wil underscore Evers at doosys dot com]


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Wil Evers <bouncer@dev.null> wrote in message news:<a14c77$3dv$1@news1.xs4all.nl>...
> >> Anyone who has tried the 'C++ with
> >> pthreads' combination will testify that the issue is not how to create
> >> a thread, or how to obtain and release a lock.  Instead, here are some
> >> of the issues I encountered:
> >>
> >> (*) how to get a thread that is being cancelled to do C++ stack unwinding
> >> (*) how to inform dependent threads about a C++ exception in some other
> >> thread
> >> (*) how to deal with asynchronous events, such as signals
> >> (*) how to wait for the first of one of multiple events (such as
> >> readiness to do I/O, or the availability of an item on a job queue)
> >> without having to spawn a thread for each event monitored
> >> (*) how to avoid races when constructing objects with static storage
> >> duration
> >
> > Good questions that all sound familiar.  It seems to me most or all of
> > them came up during the design discussions.
>
> I'm sure they did, but what happened with these discussions?

They are available in the Boost List archives.

The outcomes are reflected in the docs, example programs, etc.

>  Please note
> that it is close to impossible to write a robust multi-threaded C++ program
> without solving at least some of the issues I mentioned above.
>
> For example, it is very awkward to implement a clean program shutdown
> without using some form of thread cancellation.  The RAII idiom could be a
> big help here - if we had sufficient library support.
>
> Another example: a relatively simple abstraction like a producer/consumer
> item queue is unnecessarily hard to implement if one of the participating
> threads can disappear because of a C++ exception and all you have is
> mutexes and condition variables.
>
> > If they aren't covered in
> > the docs, you might want to post them on the Boost list.
>
> I could, but the problem is I'm unable to contribute to any real solution
> because of Boost's source licensing requirements, which are unacceptable to
> my employer (and to me).

Contributing code is only one of the ways to participate.  Posting
chanllenging questions on the mailing list helps a lot too.

>  That aside, why not discuss the feature set of a
> future standard C++ threading library in the appropriate newsgroup for C++
> standardization? [followups set to comp.std.c++].

Whew!  Boost's mailing list is high volume, covers a lot of Boost
specific topics, is tightly moderated, and is aimed a very specific
audience.  We also don't know when we start talking about a library if
it will turn out to be of interest for standardization. Not all are.
You wouldn't want our discussions on comp.std.c++!

Also, the standards committee is going to focus on existing practice.
Boost, and other non-committee places, are where the innovation is
coming from this time around.

--Beman Dawes

--Beman
---
[ 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 article <3d85f8df.0201021825.4ebf14b6@posting.google.com>, Beman Dawes
wrote:

> Wil Evers <bouncer@dev.null> wrote in message
> news:<a0uo66$bo9$1@news1.xs4all.nl>...
>
>> Had a quick look at the Boost.Threads library documentation, and, with
>> all due respect, I have to say I am disappointed.  In its current
>> state (the documentation was last updated on the 5th of November),
>> this library provides support for:
>>
>> (*) mutexes and locks
>> (*) condition variables
>> (*) thread creation and joining
>> (*) thread-local storage
>
> The intent is to keep the library minimal.  There are some additional
> features planned, but not a whole lot.  If you go back through the
> literature, it turns out that only a fairly small number of
> multi-threading constructs have a sound basis.  It's like the goto
> issue.  Yes, there are a lot of possible ways to compose a program,
> but you are better off to limit program structure to a small number of
> well understood constructs.  Ditto for concurrent programming.

I understand your point.  Library design is a delicate balancing act
between providing too much, where the library becomes bloated with features
that are nice to have, but poorly understood and implemented, and not
providing enough, where users don't find what they're looking for, and
wander off to find something else, or invent their own solutions.

In my opinion, the Boost.Threads library, in its current state, appears to
suffer from the second syndrome: it does not provide enough to qualify as a
basis for a future standard C++ threading library.  Please see below.

[snip]

>> Anyone who has tried the 'C++ with
>> pthreads' combination will testify that the issue is not how to create
>> a thread, or how to obtain and release a lock.  Instead, here are some
>> of the issues I encountered:
>>
>> (*) how to get a thread that is being cancelled to do C++ stack unwinding
>> (*) how to inform dependent threads about a C++ exception in some other
>> thread
>> (*) how to deal with asynchronous events, such as signals
>> (*) how to wait for the first of one of multiple events (such as
>> readiness to do I/O, or the availability of an item on a job queue)
>> without having to spawn a thread for each event monitored
>> (*) how to avoid races when constructing objects with static storage
>> duration
>
> Good questions that all sound familiar.  It seems to me most or all of
> them came up during the design discussions.

I'm sure they did, but what happened with these discussions?  Please note
that it is close to impossible to write a robust multi-threaded C++ program
without solving at least some of the issues I mentioned above.

For example, it is very awkward to implement a clean program shutdown
without using some form of thread cancellation.  The RAII idiom could be a
big help here - if we had sufficient library support.

Another example: a relatively simple abstraction like a producer/consumer
item queue is unnecessarily hard to implement if one of the participating
threads can disappear because of a C++ exception and all you have is
mutexes and condition variables.

> If they aren't covered in
> the docs, you might want to post them on the Boost list.

I could, but the problem is I'm unable to contribute to any real solution
because of Boost's source licensing requirements, which are unacceptable to
my employer (and to me).  That aside, why not discuss the feature set of a
future standard C++ threading library in the appropriate newsgroup for C++
standardization? [followups set to comp.std.c++].

[snip]

>> my guess is we need a uniform model to
>> deal with all sorts of inter-thread, inter-process, and inter-machine
>> communication, which could mean that a threading library would have to be
>> integrated with a library for IPC (TCP/IP).  Perhaps the ideas in Hoare's
>> Communicating Sequential Processes are a good place to start.
>
> The objective for Boost.Threads was limited to threads, in the hopes
> of keeping the project doable.

Last year, Stroustrup said standard library support for TCP/IP was one of
the priorities for C++0x.  Given that, what could be more natural then to
supply a common interface for all forms of communication between
independently running instruction sequences, where it doesn't matter if
they're part of the same process, living in a different process on the same
machine, or elsewhere on the Internet, while still taking advantage of the
best communication medium available (core memory, local sockets and pipes,
or the network)?

One might think that this is a simple matter of supplying a new interface
on top of independently developed lower level facilties, but unfortunately,
that is not the case.  If we want to be able to have a single thread wait
for the first of several communication events coming from different sources
and/or media, some notion of that commonality must be designed in at a
lower level: UNIX has file descriptors and poll()/select(), and Win32 has
event handles and WaitForMultipleObjects().

Hoare's CSP is an example of a more elegant way to express such constructs,
and I would expect a future standard C++ library to contain something
equally powerful.

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[Wil underscore Evers at doosys dot com]


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]