[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2006-03-08 (11:32) |
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 ------------------------------------------------------------