| Safe Haskell | Safe-Inferred |
|---|---|
| Language | Haskell2010 |
Data.IORef.Compat
Synopsis
- module Data.IORef
- modifyIORef' :: IORef a -> (a -> a) -> IO ()
- atomicModifyIORef' :: IORef a -> (a -> (a, b)) -> IO b
- atomicWriteIORef :: IORef a -> a -> IO ()
Documentation
module Data.IORef
modifyIORef' :: IORef a -> (a -> a) -> IO () #
Strict version of modifyIORef.
This is not an atomic update, consider using atomicModifyIORef' when
operating in a multithreaded environment.
@since base-4.6.0.0
atomicModifyIORef' :: IORef a -> (a -> (a, b)) -> IO b #
A strict version of atomicModifyIORef. This forces both the
value stored in the IORef and the value returned.
Conceptually,
atomicModifyIORef' ref f = do -- Begin atomic block old <-readIORefref let r = f old new = fst rwriteIORefref new -- End atomic block case r of (!_new, !res) -> pure res
The actions in the "atomic block" are not subject to interference
by other threads. In particular, the value in the IORef cannot
change between the readIORef and writeIORef invocations.
The new value is installed in the IORef before either value is forced.
So
atomicModifyIORef' ref (x -> (x+1, undefined))
will increment the IORef and then throw an exception in the calling
thread.
atomicModifyIORef' ref (x -> (undefined, x))
and
atomicModifyIORef' ref (_ -> undefined)
will each raise an exception in the calling thread, but will also
install the bottoming value in the IORef, where it may be read by
other threads.
This function imposes a memory barrier, preventing reordering around the "atomic block"; see Data.IORef for details.
@since base-4.6.0.0
atomicWriteIORef :: IORef a -> a -> IO () #
Variant of writeIORef. The prefix "atomic" relates to a fact that
it imposes a reordering barrier, similar to atomicModifyIORef.
Such a write will not be reordered with other reads
or writes even on CPUs with weak memory model.
@since base-4.6.0.0