Am Mittwoch, den 21.05.2008, 09:06 +0100 schrieb Martin Berger:
> Here I disagree. Shared  memory concurrency is a specific form
> of message passing: Writing to a memory cell is in fact sending
> a message to that cell carrying two items, the new value and a
> return channel that is used to inform the writer that sending
> has succeeded, and likewise for reading. This way of thinking
> about shared memory concurrency has enabled the construction of
> powerful logics and typing systems to reason about shared memory.

But this is still academic, right? The practice is that there is almost
no utility that helps programmers to write (more) correct code.

> I agree with the spirit of your claim though: shared memory is
> a form of message passing that is especially difficult.

> > With "reasoning" I don't necessarily mean formal techniques. The more
> > frequent case is that the programmer thinks about the program guided by
> > the laws of logic.
> > 
> > The impossibility to do this with truly parallelized code is an
> > important source of bugs, so I would say this code inherently more
> > buggy.
> 
> There is a lot of truth in what you say, but if you consider complex
> event handling programs, you essentially do concurrent programming,
> wether you like it or not. You just don't call it by that name.

Of course, it is possible to e.g. develop locking mechanism in event
handling programs, and then to run into the same problems. My experience
is different, however. The worst thing I've encountered so far in
practice is the "forgotten continuation" so that the event system
freezes. 

Another result from using this is in practice is that it is
comparatively easy to debug synchronization problems, because the
debugging code is not itself concurrent code. This is different to e.g.
multi-threaded programs where the whole program is concurrent, and you
cannot locally escape from this environment.

> > This is simply nonsense. Different concurrency techniques have different
> > problems. For example, in event handling-based concurrency you do not
> > need locks, hence you cannot run into deadlocks.
> 
> I disagree, but as the issue has already been dealt with by other
> posters, I shall leave it at that.

Granted, "cannot run into deadlocks" is too strong.

> > Maybe in a mainstream language, but in FP I found it always relatively
> > easy to do it.
> 
> Maybe you are an especially skilled programmer. Or maybe the applications
> that you have coded are not demanding in terms of concurrency.

Well, it's probably one of the biggest programs that has ever been coded
in O'Caml... It's a search engine (wink.com), and I would say it is very
demanding in terms of concurrency.

Keep in mind that I am not a researcher. When I make statements, then
from a practical point of view. My observation is simply that you run
far quicker into complicated synchronization problems with shared memory
concurrency than with the types of concurrency I prefer.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------