A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://hackage.haskell.org/packages/archive/base/4.5.0.0/doc/html/Data-IORef.html below:

Data.IORef

Description

Mutable references in the IO monad.

IORefs

atomicModifyIORef :: IORef a -> (a -> (a, b)) -> IO bSource

Atomically modifies the contents of an IORef.

This function is useful for using IORef in a safe way in a multithreaded program. If you only have one IORef, then using atomicModifyIORef to access and modify it will prevent race conditions.

Extending the atomicity to multiple IORefs is problematic, so it is recommended that if you need to do anything more complicated then using MVar instead is a good idea.

Memory Model

In a concurrent program, IORef operations may appear out-of-order to another thread, depending on the memory model of the underlying processor architecture. For example, on x86, loads can move ahead of stores, so in the following example:

  maybePrint :: IORef Bool -> IORef Bool -> IO ()
  maybePrint myRef yourRef = do
    writeIORef myRef True
    yourVal <- readIORef yourRef
    unless yourVal $ putStrLn "critical section"

  main :: IO ()
  main = do
    r1 <- newIORef False
    r2 <- newIORef False
    forkIO $ maybePrint r1 r2
    forkIO $ maybePrint r2 r1
    threadDelay 1000000

it is possible that the string critical section is printed twice, even though there is no interleaving of the operations of the two threads that allows that outcome. The memory model of x86 allows readIORef to happen before the earlier writeIORef.

The implementation is required to ensure that reordering of memory operations cannot cause type-correct code to go wrong. In particular, when inspecting the value read from an IORef, the memory writes that created that value must have occurred from the point of view of the current therad.

atomicModifyIORef acts as a barrier to reordering. Multiple atomicModifyIORef operations occur in strict program order. An atomicModifyIORef is never observed to take place ahead of any earlier (in program order) IORef operations, or after any later IORef operations.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4