
never used in multi-threaded situation.
Erm, nearly all my code in Haskell is multi-threaded. One of the main reasons why I am using haskell is the low-cost light weight multi-threading. Surely this is a big win for Haskell on SMP/Numa machines - which are surely the future - as even Intel have realised they can't just keep ramping up clock speeds and have gone multi-core for their next pentium iteration. Just look at the benchmarks for the multi-cpu opteron machines!
I would hesitate to make any type unsafe for multi-threading by default - I think all the guards should be in as standard ... maybe a compile time (or run-time) flag to replace the guards with NO-OPS for single CPU machines might be a sensible option.
Since there seems to have been a bit of confusion in this thread, I thought I ought to clear it up. The issue is not about single vs. multiple CPU operation. GHC only runs code on a single CPU at the moment, due to the difficulties involved in sharing a heavily used resource (the heap) between multiple threads. The problem was whether DiffArrays should be thread-safe in the Concurrent Haskell sense, which means protecting access to the DiffArray with an MVar. Cheers, Simon

The problem was whether DiffArrays should be thread-safe in the Concurrent Haskell sense, which means protecting access to the DiffArray with an MVar.
Can you give some estimate of the cost of using an MVar in this way? Could some cheaper mechanism be provided for the special case of a mutex? e.g., the moral equivalent of disabling interrupts might be cheaper (though I'd want to look at the diffarray code again before deciding if that style of solution were appropriate). -- Alastair
participants (2)
-
Alastair Reid
-
Simon Marlow