Re: [Caml-list] Re: Where's my non-classical shared memory concurrency technology?

[Martin Berger <M.Berger@doc.ic.ac.uk>]

Jon Harrop wrote:

>> Similarly, avoiding threads removes concurrency bugs...

> I don't believe you have removed any concurrency bugs. I think you just pushed 
> them around a bit.

I couldn't agree more. If you 'avoid' concurrency by writing your own
'sequential' event handling code, you have not removed the concurrency,
you just face it in a slightly different form, and you have to
program the event handling code yourself, rather than relying
on a tried and tested library, i.e. you have an additional
source of bugs, without removing the problems that are inherent
in concurrency (e.g. deadlocks, livelocks, fairness ...). There
are reasons why writing your own concurrency mechanisms might
be the way to go, but it's a highly non-trivial endeavor.

Concurrency is hard, and no matter how one presents the concurrency
(message passing, shared memory, event handling etc), the fundamental
problems will always be there.

> Data parallelism in Microsoft's Task Parallel Library. I have no 
> use for STM  myself.

Do you have industrial experience with STM? I wonder how it
performs in industrial settings. Reading STM papers by their
inventors makes them sound like the best thing since sliced
bread, but I have a (probably irrational) feeling that it's
difficult to beat fine grained locking if one can handle
the programming difficulties their use imposes.

Martin Berger