Понимание BlockedIndefiniteOnMVar в параллельном коде - PullRequest
Новая
       21

Понимание BlockedIndefiniteOnMVar в параллельном коде

5 голосов
/ 27 июля 2011

Я задал этот вопрос в списке рассылки ghc-users и получил несколько полезных ответов, но все еще не понимает, что происходит в этом коде.

По сути, я пытаюсь понять, как я могу поймать исключение BlockedIndefiniteOnMVar для восстановления блокировки, которая, возможно, не была возвращена, и понять это исключение в целом.

Вот некоторый однопоточный код, который делает именно это: 

-- This raises the exception only once and the lock is successfully restored:
main1 = do
    lock <- newMVar ()
    lockPrint "good1" lock
    takeMVar lock 
    putStrLn "main: took lock but didn't return it!"
    -- exception is raised and lock is restored here:
    lockPrint "good2" lock
    -- no exception raised:
    lockPrint "good3" lock
    readMVar lock
    putStrLn "great success"

lockPrint :: String -> MVar () -> IO ()
lockPrint name v =  takePrint `finally` put 
    where put = putMVar v () >> putStrLn (name++": replaced lock")
          takePrint = do
               e <- try $ takeMVar v :: IO (Either BlockedIndefinitelyOnMVar ())
               let printExc = putStrLn . ((name++": ")++) . show
                   printSuccess = const $ putStrLn (name++": success")
               either printExc printSuccess e

А вот версия main, демонстрирующая поведение, которое я не понимаю. В частности, я не совсем уверен, почему возникает исключение в main, хотя я вижу, что потоки на самом деле не планируются, как я себе представляю. 

main0 = do
    lock <- newMVar ()
    forkIO $ lockPrint "good1" lock

    threadDelay 100000
    takeMVar lock
    putStrLn "main: took lock but didn't return it!"

    -- raises blocked indefinitely exception
    forkIO $ lockPrint "good2" lock

    -- this should raise no exception if we were successful above:
    putStrLn "main: long pause..."
    threadDelay 2000000
    readMVar lock
    putStrLn "great success"

Извините, у меня возникли проблемы с предложением более простого примера. Выше было скомпилировано: ghc --make -threaded -fforce-recomp experiments.hs

РЕДАКТИРОВАТЬ: Эдвард З. Ян написал очень ясный блог сообщение об этом сегодня здесь. Получается, что на это исключение нельзя полагаться при выполнении чего-либо необычного.

1 Ответ

3 голосов
/ 27 июля 2011

Попытка справиться с BlockedIndefinitelyOnMVar не очень хорошая идея. Проще использовать withMVar, чтобы всегда возвращать содержимое MVar. При этом вы не должны получать это исключение, во-первых, если у вас нет тупика (который следует рассматривать как ошибку и должен быть исправлен в коде).

...