Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-04 09:28:04

Unfortunately, it looks like things are going to once again wind down
on this subject with no real effort having been made. The few people
that seem interested in starting *somewhere* don't get very far
because of the people that first want clear definitions and what
seems (to me) to be some grand new scheme for concurrent
programming. This post is one such example that seems to me to want
a silver bullet answer, so I'll start with it and move on to my other
thoughts afterward.

--- In boost_at_[hidden], "Greg Colvin" <greg_at_c...> wrote:
> From: Valentin Bonnard <Bonnard.V_at_w...>
> > Joe Gottman wrote:
> > ...
> > > This only works, however, if there is some
> > > common interface that the template writer can assume is used by
> > > implementation.
> >
> > Indeed. Some people have questioned wether such a common
> > is realistic. But Java did it, why not C++ ?
> Java did a truly terrible job of it, in my opinion.

In some way's I'd agree. After all, a very large number of methods
originally offered are now deprecated. These methods are simply
unsafe and never should have been in the original design. This sort
of thing needs to be avoided if at all possible in any attempts to
design a library for C++. Beyond this, however, the general approach
taken by Java seems to me to be sound and based on current
knowledge. If you truly don't agree with this then offer an
alternative. With out the alternative we're back to the fact that
(at least for now) there is no such thing as a silver bullet and so
we must start somewhere.

The only "solution" I've seen for concurrent programming that _seems_
to promise full expressive power and safety is the approach outlined
by Bertrand Meyers in OOSC. However, this idea is still being
revised by Mr. Meyers and no working implementation of it exists.
Further, it relies exclusively on the language and is not something
likely to be able to be placed in a library, so it's not a path that
we can go down for C++ (at least not within the scope of Boost).

So, if we want library support within C++ I think we should start
small and build up from there slowly and carefully. This I hope
addresses the concern of those that want the mythical silver bullet.
As for those wanting to start with vast definitions...

I'm not sure why we need to do this. Most definitions are well known
to anyone who's done concurrent programming. Unless we're striving
to come up with new jargon there's nothing to define. If the problem
is simply that some here are not aware of the definitions, it seems
to me like they could easily be presented as they come up.
Concurrent programming is difficult and relies on a lot of jargon
that would need to be conveyed... jargon that I think would cloud the
issue if presented too early in this discussion.

So, I'll present the limited set of definitions that I think are
pertinent at this time:

Conncurrent programming - Programming in a fashion that takes
advantage of potential parallelism by allowing units of work to be
processed concurrently. This may not be true concurrency, but
instead could rely on "time slices" of execution being alloted for
each unit of work.

Synchronization - The process of insuring that dead locks and race
conditions don't occur between two units of work being run

Dead lock - A software bug in which a unit of work is blocked waiting
for a resource (often a synchronization primitive) that it can never

Race condition - A software bug that is dependent upon the order of
completion of two or more units of work being run concurrently.

I hope that this is enough to at least start somewhere. The area
that the group is most concerned with is in synchronization, and
that's a good place to start. There are numerous ways to do
synchronization, but the most primitive form available to library
writers is the mutex. Unless someone has some other idea, can we at
least start our discussion with this primitive?

Boost list run by bdawes at, gregod at, cpdaniel at, john at