Re: [Caml-list] STM support in OCaml

[Dan Grossman <djg@cs.washington.edu>]

Just to chime in on this thread briefly as an AtomCaml author:

* The posts have described AtomCaml fairly accurately (exploits 
uniprocessor, works only for bytecode, is integrated with the bytecode 
thread scheduler).

* AtomCaml is not "officially" supported; it demonstrates that STM 
support in OCaml is "not that hard".  That said, constructive feedback 
is welcome.

* From my perspective, the things missing are:
  1. native-code support (and yes this involves communicating with the 
kernel scheduler)
  2. STM-Haskell style combinators (I see no major problems here).
  3?. We should be clear that OCaml does not provide "true parallelism" 
(i.e., multiprocessing).  The point of AtomCaml is to show how fast STM 
can be given that.

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.
  * Multiple threads can provide isolation (if one task must abort it 
can throw an exception which terminates only one thread).

--Dan

skaller wrote:
> On Wed, 2006-03-08 at 12:32 +0100, Gerd Stolpmann wrote:
> 
> 
>>Anyway, I think this question is misleading. The point is not to
>>establish locking schemes that use the hardware better (i.e. that are
>>faster), but to help programmers writing correct code.
> 
> 
> My aim would be to do both -- they're not independent.
> Who cares about concurrency if not to try to do some job faster?
> And of course it's no good if you do the wrong thing faster :)
>