Concorrenza di Haskell - forkIO è davvero non deterministico?

Question

Sto tentando di utilizzare la concorrenza in Haskell per un'ottimizzazione specifica in cui è richiesto solo uno dei due valori e, a seconda della situazione, uno può essere molto più veloce da creare rispetto all'altro.

Ho pensato di poter eseguire solo 2 thread con forkIO e quindi attendere che un valore venga inserito in un MVar. Ecco un semplice test che ho scritto per questo:

import Control.Concurrent 

main = do out <- newEmptyMVar 
      t1 <- forkIO (makeString out) 
      t2 <- forkIO (makeInt out) 
      v <- takeMVar out 
      killThread t1 
      killThread t2 
      case v of 
       Left s -> putStrLn s 
       Right i -> putStrLn $ show i 

makeString out = do s <- return (show (primes !! 10000)) 
        putMVar out $ Left s 

makeInt out = do i <- return 2 
       putMVar out $ Right i 

primes = sieve [2..] 
where sieve (x:xs) = x : (sieve $ filter ((/=0).(flip mod x)) xs) 

Compilato con:

ghc --make -threaded Test 

Tuttavia, unico caso la sinistra s è mai raggiunto, anche se sempre il primo dovrebbe prendere abbastanza a lungo per la MAKEINT thread per iniziare (e restituire 2 in realtà non dovrebbe richiedere molto tempo). Perché è così, e come posso risolvere questo?

Answer 1

Il problema qui è la pigrizia. Il makeString sta semplicemente inserendo un thunk per calcolare show (primes !! 10000), che poi viene valutato dal thread principale in seguito. Inserire il thunk è abbastanza veloce, quindi in questo caso capita di vincere la gara.

Per forzare la valutazione avvenire entro il filo, è possibile modificare return-evaluate:

makeString out = do s <- evaluate $ show (primes !! 10000) 
        putMVar out $ Left s 

Questo dovrebbe causare makeInt per vincere la gara, nella maggior parte dei casi (anche se non è garantita).

Answer 2

Sì, i thread in realtà non sono deterministici (in GHC).

Accade semplicemente che il tuo particolare codice sia strutturato e ottimizzato in modo tale che t1 vinca sempre. Non ci sono garanzie.

Se si desidera provare a eseguire il massaggio per produrre un risultato diverso, provare ad attivare le ottimizzazioni (-O2) e/o utilizzare più core (+RTS -N).

E.g. sulla mia macchina, due piste di fila:

$ ghc -O2 -threaded --make A.hs -rtsopts -fforce-recomp 
[1 of 1] Compiling Main    (A.hs, A.o) 
Linking A.exe ... 
$ ./A +RTS -N2 
2 
$ ./A +RTS -N2 
104743 

Come sottolinea Hammar, è anche possibile strutturare il codice per forzare più di lavoro che si terrà nel thread (o passare a using strict mvars).