Re: Threads

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 
any
> > > implementation.
> > 
> > Indeed. Some people have questioned wether such a common 
interface 
> > 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 
concurrently.

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 
acquire.

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?