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