On 12/01/2012 17:55, Johan Tibell wrote:

On Thu, Jan 12, 2012 at 12:54 AM, Simon Marlow wrote:

...

For boxed arrays you need a PrimOp of course (like catMutVar#). For unboxed arrays you could get away with FFI, but a PrimOp would be better because it could be inline. But to get it inline would mean modifying the native and LLVM backends to support CAS operations.

If I were you I would use FFI for now. The cost of the out-of-line call is much less than the cost of the CAS anyway. A gcc dependency is not a big deal, it's available on all Unix-like platforms and I don't see us removing it from the Windows installs any time soon.

In a recent project (http://hackage.haskell.org/package/ekg) I found myself wanting unboxed mutable integers with CAS semantics (to implement simple counters). What would be required to support

(1) unboxed mutable variables, and (2) CAS semantics for these.

I guess (2) is easy once you have (1). Just add some new primops.

I think by (1) you mean mutable variables containing unboxed values, right? I normally use an unboxed array of length 1 for these. There's not much overhead - only an extra word in the heap compared to implementing them natively. I'm guessing you care more about the overhead of the operations than the space overhead of the counter itself, and a 1-element unboxed array should be just fine in that respect. Cheers, Simon