Re: Threads

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.

[snip]

> 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* 
before
> 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 
would
> not be opposed to a working solution even if it has some edges I 
don't
> 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.