Boost logo

Boost :

From: Beman Dawes (beman_at_[hidden])
Date: 2000-08-04 12:46:33

William Kempf wrote:

>> What base document do we look at for the definition of a mutex?
>I provided the definition in another post, so I won't state it
>again. I admit that I should have given the definition of a mutex
>before asking the question you quote above. However, the fact that
>you asked this begs a question to me. Why are you asking what a
>mutex is?

Several reasons, including a personal one; I may be the one who has to
stand up in front of the C++ committee and try to convince them a boost MT
library is good enough to standardize. They will ask me for the source of
the definitions, among other things. They will loose interest right away if
the answers to questions are vague arm waving. They also believe that many
otherwise successful programming languages and libraries have been
seriously flawed in handling of concurrent programming issues. So the bar
is set very high.

>I fully agree that we need to have definitions for everything we
>discuss here, and I can see the need for a formal definition being
>given before terms are used here (and possibly revised as the
>discussion progresses). However, there are several definitions that
>are well known, and a mutex is one such. Other areas of boost have
>been discussed and worked on here with out formal definition of well
>known terms within their area of use. Is the problem here that not
>enough people are familiar with the basic terms of cuncurrent
>programming, or is it something else that I'm missing. I ask so that
>I know how to proceed in this discussion.

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.

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

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.

Good Luck!



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