On Monday 19 May 2008 15:09:04 Gerd Stolpmann wrote:
> On the contrary: Shared memory parallelization has the fundamental
> disadvantage that you cannot reason about it,

I have been reasoning about shared memory parallel programs for many years.

> and so the only way of checking the quality of the code is testing.

I often assess the correctness of my parallel codes just by reading them.

> Event handing concurrency, while not giving you parallelization, is
> basically sequential programming, and it is possible to reason about such
> programs. 

Programs are parallelized in the interests of efficiency. Event handling 
concurrency is orders of magnitude less efficient in the context of 
CPU-intensive tasks that are not embarassingly parallel so it is not an 
alternative.

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

Then it is a subjective belief.

> The impossibility to do this with truly parallelized code is an
> important source of bugs, so I would say this code inherently more
> buggy.

Your remit is concurrency and not parallelism.

> > i.e. you have an additional
> > source of bugs, without removing the problems that are inherent
> > in concurrency (e.g. deadlocks, livelocks, fairness ...).
>
> 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.

Two agents cannot proceed because they are waiting on events from each other 
=> they are deadlocked even though there are no mutexes.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e