ANN: Monad.Reader Issue 19
I am pleased to announce that Issue 19 of The Monad.Reader, a special issue on parallelism and concurrency, is now available: http://themonadreader.files.wordpress.com/2011/10/issue19.pdf Issue 19 consists of the following three articles: * Mighttpd – a High Performance Web Server in Haskell by Kazu Yamamoto * High Performance Haskell with MPI by Bernie Pope and Dmitry Astapov * Coroutine Pipelines by Mario Blažević Feel free to browse the source files. You can check out the entire repository using darcs: darcs get http://code.haskell.org/~byorgey/TMR/Issue19 If you’d like to write something for Issue 20, please get in touch. The deadline will likely be in December; more details will be forthcoming.
On 26 October 2011 21:17, Brent Yorgey <byorgey@seas.upenn.edu> wrote:
I am pleased to announce that Issue 19 of The Monad.Reader, a special issue on parallelism and concurrency, is now available:
Thanks, I always really enjoy The Monad.Reader.
Issue 19 consists of the following three articles:
* Mighttpd – a High Performance Web Server in Haskell by Kazu Yamamoto
Kazu, really interesting article! I have one question regarding your use of atomicModifyIORef: x <- atomicModifyIORef ref (\_ -> (tmstr, ())) x `seq` return () Can't you write that as just: writeIORef ref tmstr? If you're not using the previous value of the IORef there's no chance of inconsistency. I looked in the git repository of mighttpd2 and it seems that in the FileCache module we can make a similar change by rewriting: remover :: IORef Cache -> IO () remover ref = do threadDelay 10000000 _ <- atomicModifyIORef ref (\_ -> (M.empty, ())) remover ref to: remover :: IORef Cache -> IO () remover ref = forever $ do threadDelay 10000000 writeIORef ref M.empty Regards, Bas
On Wed, Oct 26, 2011 at 4:24 PM, Bas van Dijk <v.dijk.bas@gmail.com> wrote:
I have one question regarding your use of atomicModifyIORef:
x <- atomicModifyIORef ref (\_ -> (tmstr, ())) x `seq` return ()
Can't you write that as just: writeIORef ref tmstr? If you're not using the previous value of the IORef there's no chance of inconsistency.
From the documentation at http://hackage.haskell.org/packages/archive/base/latest/doc/html/Data-IORef.... :
IORef operations may appear out-of-order to another thread, ... ... atomicModifyIORef acts as a barrier to reordering. Multiple atomicModifyIORef operations occur in strict program order. Based on this description, it seems that atomicModifyIORef is safer for writing to an IORef than writeIORef when there are multiple threads reading and writing it. If my assessment is correct, I think Data.IORef should have an atomicWriteIORef :: IORef a -> a -> IO () function to clarify this. I'm not completely sure about this myself. Could someone confirm this? Moreover, it'd be nice if there were writeIORef' and atomicModifyIORef' functions that force the value. Doing so would help people avoid making the mistake described by the author. It's a really common mistake. - Joey
participants (3)
-
Bas van Dijk -
Brent Yorgey -
Joey Adams