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