On Tue, 2003-11-04 at 13:41, Alastair Reid wrote: > I was thinking that, if the current mutex implementation is killing > performance (and it is an assumption - though one of the Simons could > probably confirm or deny it), we should look to see if mutexes can be made > cheaper or rewrite the code to avoid it or ... For example, the Java > community has done a lot of work on how to make it cheap to take an > uncontested lock but more expensive to take a contested lock.
In the next Linux kernel (2.6.x) you can implement mutexes using 'futex'es which in the uncontested case cost 1 atomic memory increment/decrement operation plus 1 register to register comparison. In the contested case it still requires a kernel call. Of course this is for mutexes for OS threads/processes. An implementation for a pure user space thread implementation like ghc's might be even simpler / cheaper (although it'd be hard to find an implementation cheaper than 1 atomic memory operation!). Duncan _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
