Boost logo

Boost :

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

--- In boost_at_[hidden], Dietmar Kuehl <dietmar_kuehl_at_y...> wrote:
> Hi,
> apparently you are in an extreme hurry and you want to start doing
> things at some more or less random point: Mutex? Who cares about
> mutexes? What is the point of a mutex?

No, I'm not in a hurry. I'm just extremely interested in the
subject. I'm fine with things progressing slowly. The only reason
I'm trying to start somewhere here is to generate discussion again.
The last time this subject came up there was heated debate for about
3 days and then the subject died entirely until I brought it up
again. I simply don't want the idea to die that easily. I suggest
starting with a mutex because it's the fundemantal building block for
every other thread synchronization concept. You mention that Java
doesn't have them... but it does. The language is able to hide them,
but they still exist. I don't think it will be possible to hide them
this way in our case since we're looking for a library solution and
not a language solution.


> Also note that I'm not seeking a completely new approach solving all
> problems at once! I'm just seeking an agreement on the *problem*
> looking for a solution. Of course, I hope that we can come up with a
> superior solution to the problem when going this direction but I
> not be opposed to a working solution even if it has some edges I
> like.

Very good summary of the topic. This is probably what the others
have been trying to tell me and I've just not been getting it. I can
see your points, and in the end I fully agree with them. However,
the basic problem at hand isn't that hard to define. There's
actually three problems that I see. The first is synchronizing
threads (I gave a definition of what this means earlier). The second
is creation of threads. The third is scheduling of threads. We
don't need to address all three problems at once. You yourself
mentioned being mostly interested in the first problem, so I tried to
start there. I started low to try and generate discussion, and maybe
in doing so I'm limiting the possible final result. Any
synchronization scheme devised is going to rely on a mutex under the
covers, but starting there may well lead to overlooking some higher
level abstraction.

I guess that to me the problems are self evident. What's not self
evident are the solutions beyond those that already exist. The
solutions that already exist can be a good starting point for
extrapolating new solutions, but the problem here is that the
existing solutions are very platform specific. I was thinking we
could define an interface that was similar to the existing solutions
but that were platform neutral and could be implemented on any
platform. At that point we'd have a starting place for other
abstractions on the problem domain. Even with the danger that this
might limit the later abstractions I still think that it's a viable
place to start. I can see why others may not agree with this,
though. I really don't have the answer here, I just don't want the
effort to die simply because no one has the answer.

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