Re: Threads

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-04 14:02:32

--- In boost_at_[hidden], Beman Dawes <beman_at_e...> wrote:
> In most other boost discussion, people use well-known terms which 
are in 
> fact just that: well-known and generally agreed upon.  You can go 
to 
> standard references like Knuth, Sedgewick, or various ISO 
publications, 
> find reasonably agreeing definitions, and bibliographies which 
trace the 
> ideas back to respected original sources.

A mutex is no different, at least to my mind, than any of these other 
terms.  For instance, the defininition of a virtual function.  The 
implementation details, which in fact is what you're having problems 
with here, are not part of the definition of what a virtual function 
is.
 
> It seems to get a lot fuzzier with multiprogramming topics.  Your 
> definition of mutex, for example, had fairly profound differences 
from 
> those given by POSIX, Win32, and Butenhof (the sources I have in 
front of 
> me).

No, my definition did not.  POSIX and Win32 both define a mutex the 
same way.  It's nothing more than a primitive used to allow mutually 
exclusive access to a shared resource.  They don't differ in this 
definition at all.  How they do differ is in the implementation.  A 
Win32 mutex is recursive while a POSIX mutex is not, for instance.  
These differences in no way change the definition of the term.  
(Sorry, I'm not familiar with Butenhof to comment there in the same 
manner that I commented on POSIX and Win32.)

>  There are not so many sources available either; the 
> comp.programming.threads FAQ lists mostly sources that relate to 
specific 
> packages rather than basic concepts.  Dijkstra, Hoare, and other 
original 
> sources of concurrent programming ideas don't seem to have matured 
into 
> generally agreed right way to do it.  Let along how to design 
libraries 
> which interact well.

This much is true.  Concurrent programming is severely complex and 
I'm not at all sure that we're anywhere close to knowing "the right 
way to do things".  To my mind, the right way will require something 
beyond a library.  Mr. Meyer has some good thoughts on this in OOSC.  
His ideas, however, are in their infancy even after all the years 
since he first published the idea.  No working model yet exists so no 
one knows what problems will result once a working model does exist.

To my mind, this does not constitute a reason not to explore the 
subject.  In fact, it does the opposite.  If we were to wait until 
that elusive silver bullet appears we'd never find it.  All that I am 
suggesting is two things:  we have concurrent programming today 
whether you like it or not, so at the bare minimum we need some way 
to write "thread safe" code and any attempt at a solution for this, 
especially a solution in the form of a C++ library, must start with 
primitives such as the mutex.
 
> So if you want to proceed, 1) go back and read all the boost 
Threads 
> discussions, and 2) search the general literature and do other 
homework, 3) 
> write a goals and definitions document we can critique, discuss, 
and 
> ultimately agree upon.  Make sure it covers the impact of threading 
issues 
> on other libraries; that is where the rubber hits the road.

I've done (1) or I wouldn't be posting here.  I've also done (2), 
though I fully admit to not being an expert on the subject at this 
time (very few people can claim to be an expert on this one, but I've 
at least got extensive research and real world experience).  As for 
(3)... maybe I'm going about this wrong.  It makes more sense to me 
to discuss the problem domain before throwing together a design.  You 
seem to be suggesting to do this the other way around.