Proposal: Add atomic IORef operations to Data.IORef

Alexey Kuleshevich alexey at
Fri Jan 15 20:18:58 UTC 2021

Both of these functions are lazy with respect to the new value being written into the IORef, which is a horrible default for atomic operations. That is why atomicModifyIORef is a source of memory leaks and terrible performance, which is also why atomicModifyIORef' is almost always used instead.

So +1 from me on adding strict versions of these functions that force new value to whnf, but -1 for adding these lazy versions as they are currently defined in GHC.IORef


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, January 15, 2021 11:05 PM, David Feuer <david.feuer at> wrote:

> GHC.IORef currently exports
> atomicModifyIORef2 :: IORef a -> (a -> (a,b)) -> IO (a, (a, b))
> atomicSwapIORef :: IORef a -> a -> IO a
> atomicModifyIORef2 is a lot like atomicModifyIORef, but it returns
> both the old value in the IORef and the full result of applying the
> user-supplied function to that. This is a pretty thin wrapper around
> the newish atomicModifyMutVar2# primop, which has replaced the less
> powerful atomicModifyMutVar#.
> atomicSwapIORef atomically installs a user-supplied value in an IORef
> and returns the old value. It is currently implemented using
> atomicModifyIORef2, but it can and should be reimplemented using its
> own, more efficient primop.
> I propose to add both of these functions to Data.IORef.
> David
> Libraries mailing list
> Libraries at

More information about the Libraries mailing list