Chris Kuklewicz wrote:
> And really folks, the waitQSem(N) and signalQSem(N) should be exception
> safe and
> this is not currently true. They should all be using the modifyMVar_
> idiom — currently an exception such as killThread between the take and put
> will leave the semaphore perpetually emp
The code assumes newQsem is never given a negative argument without ever
documenting this fact.
http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Control-Concurrent-QSem.html#waitQSem
change not only
putMVar sem (0, blocked++[block])
to
putMVar sem (avail, blocked++[block]
I've now raised a ticket to track this issue:
http://hackage.haskell.org/trac/ghc/ticket/3159
Thanks, Neil
On Wed, Apr 8, 2009 at 11:26 AM, Neil Mitchell wrote:
> Hi
>
> I believe the following program should always print 100:
>
> import Data.IORef
> import Control.Concurrent
>
> main = do
>
Hi
I believe the following program should always print 100:
import Data.IORef
import Control.Concurrent
main = do
sem <- newQSem (-99)
r <- newIORef 0
let incRef = atomicModifyIORef r (\a -> (a+1,a))
sequence_ $ replicate 100 $ forkIO $ incRef >> signalQSem sem
waitQSem sem
