Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] STM support in OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] STM support in OCaml
Am Mittwoch, den 08.03.2006, 11:11 +0100 schrieb yoann padioleau:
> > > You make several claims:
> > > 
> > > STM is not lock free.
> > > STM is not useful on a small number of processors
> > > 
> > > As for claim 1.  "Lock-free" doesn't mean what you think it does. 
> > 
> > I know what STM does, thank you: I intend to implement it
> > myself in my own programming language. Maybe you should
> > read more carefully.
> > 
> > I said "protected by a mutex under the hood." which means
> > sure, the programmer is not writing locks, but they're used
> > in the implementation and the associated costs are still paid.
> 
> I have read (very fastly) the atomcaml paper and I don't think they use "mutex under the hood".
> It seems that they just log stuff and rollback. I guess that when you want to implement 
> STM on multiprocessor you may need to mutex stuff (the internal data structures maintained by the STM runtime),
> but as ocaml runtime does not use multiprocessor, they dont need it.

In Atomcaml, the question whether there is a mutex or not simply does
not matter. They have their own scheduler (for bytecode), so there is no
need to have additional mutexes to protect the data structures Atomcaml
needs for itself, e.g. the log buffer. Being the scheduler is better
than any mutual exclusion...

If you ported Atomcaml to a kernel-level scheduler, you would surely
need mutexes (even in the uniprocessor case), simply because you need to
synchronize the kernel scheduler with user-level atomicity management.
So yes, for any real-world implementation, there are "mutexes under the
hood".

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.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------