[
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-07 (19:03) |
From: | Asfand Yar Qazi <email@a...> |
Subject: | Re: [Caml-list] STM support in OCaml |
skaller wrote: > On Tue, 2006-03-07 at 16:18 +0000, Asfand Yar Qazi wrote: > >>Hi, >> >>I've temporarily decided to leave off learning OCaml (although I still intend >>to learn it at some point) and start learning Haskell due to its support for >>Software Transactional Memory and lock-free concurrent programming. > > > AFAIK STM is not lock free. It simply limits the locking period > to a bounded time, at the expense of the whole transaction > taking unbounded time. The final compare/write/retry must > be atomic and is therefore protected by a mutex under the hood. > > Sebastian Egner said in another post the main advantage > of STMs: they have a combinator form, that is, they > can be composed. > > However, despite the lack of safety in a bolt on > addition for Ocaml .. the real problem is that STM > isn't that useful unless you have > > (a) a lot of processors > (b) a lot of variables > > so that the risk of contention is low and the cost > of long exclusions is high. Ocaml fails to satisfy > property (a) since it doesn't support multi-processing. > You make several claims: STM is not lock free. STM is not useful on a small number of processors With all due respect, these papers refutes these claims: http://research.microsoft.com/~simonpj/papers/stm/index.htm http://research.microsoft.com/~simonpj/papers/stm/lock-free.htm (That's right - the premier research on STM is being done by Micro$oft - yuck.) As for claim 1. "Lock-free" doesn't mean what you think it does. Quote from first paper, page 11: "The STM implementation guarantees that one transaction can force another to abort only when the first one commits. As a result, the STM implementation is lock-free in the sense that it guarantees at any time that some running transaction can successfully commit." As for claim 2, note the two-processor performance graphs of their tests (second paper, "lock-free.htm", pages 14-15): STM blows the hell out of conventional lock-based parallel processing. As for the lot of variables bit, I intend to have a lot of the buggers :-)