Unboxed mutable variables (was: Easiest way to extend CAS (casMutVar#) to boxed/unboxed Vector elements?)

Simon Marlow marlowsd at gmail.com
Thu Jan 12 19:25:25 CET 2012

On 12/01/2012 17:55, Johan Tibell wrote:
> On Thu, Jan 12, 2012 at 12:54 AM, Simon Marlow<marlowsd at gmail.com>  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.


More information about the Glasgow-haskell-users mailing list