[Haskell-cafe] ANN: concurrent-extra-0.1
Hello, We would like to announce the release of concurrent-extra [1]. A library which offers a few extra synchronization primitives. These primitives are found in the standard libraries of languages like Java and Python, but not in Haskell. Quick overview: * Lock: Enforce exclusive access to a resource. Also known as a mutex or a binary semaphore. * RLock: A lock which can be acquired multiple times by the same thread. Also known as a reentrant mutex. * Event: Wake multiple threads by signaling an event. Includes both pessimistic and optimistic versions. * ReadWriteLock: Multiple-reader, single-writer locks. Used to protect shared resources which may be concurrently read, but only sequentially written. * ReadWriteVar: Concurrent read, sequential write variables. Plug Play: cabal install concurrent-extra Darcs: darcs get http://code.haskell.org/~roelvandijk/code/concurrent-extra/ Thanks to Neil Brown and Simon Marlow for an initial review. Comments are still more than welcome! Regards, Roel Bas van Dijk [1] http://hackage.haskell.org/package/concurrent-extra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: concurrent-extra-0.1
Hello, Thanks for the release! On Wed, Feb 17, 2010 at 03:10:38PM +0100, Roel van Dijk wrote: * RLock: A lock which can be acquired multiple times by the same thread. Also known as a reentrant mutex. In acquire (l. 111), if the lock was already acquired it goes by | otherwise → do putMVar mv mb Lock.acquire lock So it puts back the information about the owner of the RLock and waits for its release in the normal Lock. And then... nothing? Shouldn't it need to put into mv information about itself? In release (l. 142) Nothing is put into mv then do Lock.release lock putMVar mv Nothing Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: concurrent-extra-0.1
On Wed, Feb 17, 2010 at 3:27 PM, Felipe Lessa felipe.le...@gmail.com wrote: In acquire (l. 111), if the lock was already acquired it goes by | otherwise → do putMVar mv mb Lock.acquire lock So it puts back the information about the owner of the RLock and waits for its release in the normal Lock. And then... nothing? Shouldn't it need to put into mv information about itself? Well spotted! In order to fix this we changed the structure of an RLock a bit. The inner lock isn't contained in a Maybe anymore but directly in the MVar. So now there is only 1 Lock associated with an RLock. This makes reasoning about the control flow a bit simpler. We also added a test case which fails on the original code but succeeds with the new version. In release (l. 142) Nothing is put into mv then do Lock.release lock putMVar mv Nothing I'm not sure if that was a bug in the original. In the new version we put the lock back inside the MVar. Current version: http://hackage.haskell.org/package/concurrent-extra-0.1.0.1 Thanks, Roel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: concurrent-extra-0.1
On Wed, Feb 17, 2010 at 05:11:45PM +0100, Roel van Dijk wrote: On Wed, Feb 17, 2010 at 3:27 PM, Felipe Lessa felipe.le...@gmail.com wrote: In release (l. 142) Nothing is put into mv then do Lock.release lock putMVar mv Nothing I'm not sure if that was a bug in the original. In the new version we put the lock back inside the MVar. I think it was workable, I've referenced the code just to make the e-mail more self-contained. That Nothing was going to stay after the inner Lock was acquired. :) Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
