Re: [Caml-list] STM support in OCaml

[skaller <skaller@users.sourceforge.net>]

On Wed, 2006-03-08 at 11:22 -0800, Dan Grossman wrote:

> As for "why concurrency if not to run faster", there _are_ other reasons 
> for certain applications:
>   * Multiple threads are a natural match for computations that are 
> naturally decomposed into multiple control contexts.

Yes, but one only uses *pre-emptive* threads here if the language
fails to provide control inversion/synchronous threads.
With synchronous threads you have interleaving, but no
concurrency. Felix, MLton, and Haskell provide synchronous
threads. 

Pre-emptive threads are less useful by comparison
due to their exceptionally poor performance on most OS,
limitations to their numbers, and the need for use of
interlocking primitives (mutex etc) which are generally
not required with synchronous threads. The latter not
only reduces performance, it also makes programming
very much more difficult. In particular, STM isn't as
useful with synchronous threads.

In fact most uses of 'multiple control contexts' call
for control inversion NOT pre-emption or concurrency:
what's required for the 'natural match' is to turn
the program 'inside out'.

Actually the idea extends to asynchronous control as well:
asynchronous callbacks, signals, or interruptions, can also
be interleaved and represented in control inverted form.
Felix is now doing both.

The effect is that as in C you would write 'read channel data'
or 'write channel data' in multiple threads. But actually
by control inverting this is turned into non-concurrent
callback/event driven code. There are indeed 'logical threads
of control' but no concurrency.

In Felix for example, we do use one thread for sockets
to synchronise the OS with the program: the end user, however,
can ignore this and write a web server supporting a million
active connections and not use a single bit of 'concurrency'.
[We could use pollling .. and indeed within the thread we
are: with epoll, kqueue, or io completion ports]

I do agree with what you're saying -- yes threads are a
natural fit for many problems. But 'concurrency' is generally
NOT what is required, and is in fact a serious obstacle to
both performance and ease of programming.

But it all depends on what you mean by 'concurrent'. The word
of course really does imply parallelism: con-current means
literally 'at the same time' which is generally impossible
on a uniprocessor (except perhaps for DMA, H/W accelerated
graphics, etc .. but then really you do have more than one
processor :)

Anyhow all this is just to say: lets not confuse the
need for Concurrency with the need for Control Inversion.

-- 
John Skaller <skaller at users dot sourceforge dot net>
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net