Boost logo

Boost :

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
> standard references like Knuth, Sedgewick, or various ISO
> 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
> It seems to get a lot fuzzier with multiprogramming topics. Your
> definition of mutex, for example, had fairly profound differences
> 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
> packages rather than basic concepts. Dijkstra, Hoare, and other
> sources of concurrent programming ideas don't seem to have matured
> generally agreed right way to do it. Let along how to design
> 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
> discussions, and 2) search the general literature and do other
homework, 3)
> write a goals and definitions document we can critique, discuss,
> ultimately agree upon. Make sure it covers the impact of threading
> 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.

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