Implementing Concurrent Futures in Concurrent Haskell

Transcription

1 Implementing Concurrent Futures in Concurrent Haskell Working Draft David Sabel Institut für Informatik Johann Wolfgang Goethe-Universität Postfach D Frankfurt, Germany January 28, Introduction We present an implementation of futures in Concurrent Haskell. Futures are variables whose value is initially not known, but becomes available in the future when the corresponding computation is finished. The futures presented in this paper are concurrent, i.e. the computation necessary to obtain the value of a future is performed in a concurrent thread. We present explicit futures, i.e. where the value of a future must be explicitly forced and more importantly we also implement implicit futures. Implicit futures can be used like any other reference, and to obtain the value of a future there is no need to explicitly force the future. The advantage of futures is their easy use: for a lot of applications futures can be used as basic concurrency primitive without taking explicitly care about the synchronization of concurrent threads. Moreover, the futures perform this synchronization automatically. 2 Concurrent Haskell Concurrent Haskell was proposed in [PGF96], but its current implementation in the Glasgow Haskell Compiler is slightly modified. In this paper we refer to the concurrent implementation in the GHC (a description can also be found in [Pey01]), and give a short overview of some basic constructs of Concurrent Haskell. Concurrent Haskell extends Haskell by a primitive forkio and by synchronizing variables MVar which behave like single one-place buffers: MVars are either empty or filled. The primitive operation newemptymvar creates an empty MVar. The operation takemvar reads the value of a filled MVar and empties it, and blocks the calling thread if the MVar is empty until the MVar becomes filled. Similarly, putmvar v e writes the expression e into the MVar v, if v is empty, and blocks otherwise until the MVar becomes empty. The primitive for thread

2 2 David Sabel creation in Concurrent Haskell is forkio :: IO () -> IO ThreadId. Applied to an IO-action, a concurrent thread is immediately started to compute the action concurrently. From the perspective of the calling thread, the result is a unique identifier of the concurrent thread, which for instance can be used to kill the concurrent thread using killthread. As already observable by the type of forkio, the result of the concurrently started IO-action must be the unit type () (packed in the IO-monad), and the result of forkio itself is only a thread identifier. Using forkio and MVars one can implement explicit futures. The implementation is shown in Fig. 1. An explicit future is represented by an MVar. The creation of an explicit future first creates an empty MVar and then starts the computation of the action corresponding to the future in a concurrent thread such that after finishing the computation the result is written into the empty MVar. From the view of the calling thread a future in form of an MVar is immediately returned. If the value of the future is needed then the future must be forced explicitly by calling force which reads the MVar. If the future value is not computed already, then a wait situation arises until the concurrent computation is finished. A use case for (explicit) futures is shown on the right hand side of Fig. 1, where a parallel binary tree sum is implemented. This example shows that it is necessary to force the evaluation of futures, and this makes programming with explicit futures uncomfortable: The programmer must be careful to force the future at the right moment. E.g., in the code of the binary tree sum it would be better to force the future futr after computing a + resl, which is possible, but increases and complicates the code. It is more desirable that the future gets (automatically) forced when it is needed such that the programmer does not need to care about explicit forces. Unfortunately, this behavior is not implementable using explicit futures. type EFuture a = MVar a efuture :: IO a IO (EFuture a) efuture act = do ack newemptymvar forkio (act >>= putmvar ack) return ack force :: EFuture a IO a force = takemvar data BTree a = Leaf a Node a (BTree a) (BTree a) treesum (Leaf a) = return a treesum (Node a l r) = do futl efuture (treesum l) futr efuture (treesum r) resl force futl resr force futr let result = (a + resl + resr) in seq result (return result) Fig. 1. Implementation of explicit futures and an example

3 Implementing Concurrent Futures in Concurrent Haskell 3 To solve this problem we use a well-known technique to delay the computation of a sequential monadic IO-computation: We use unsafeinterleaveio which is well-used to delay computations in the IO-monad and to break sequentiality. For instance, the standard implementation of readfile for lazy file reading uses unsafeinterleaveio to delay the reading of the single characters of a file. future :: IO a IO a future code = do ack newemptymvar thread forkio (code >>= putmvar ack) unsafeinterleaveio (do result takemvar ack killthread thread return result) Fig. 2. Implementation of implicit futures In Fig. 2 the implementation of implicit futures is shown. First an empty MVar is created, which will be used to store the result of the concurrent computation. This computation is created using forkio which writes its result into the futures when it becomes available. The last part consist of taking the result, killing the concurrent thread and returning the result. This part is delayed using unsafeinterleaveio. Note, that without the use of unsafeinterleaveio the calling thread would be blocked until the concurrent computation has finished which would not implement the desired behavior of futures. For the shown implementation the calling thread only becomes blocked if it demands the result of an unevaluated future. An implementation of parallel tree sum with implicit futures is shown in Fig. 3. Compared to implementation with explicit futures it is not necessary to force the futures, since they get forced automatically when their value is needed. The seq is used to return a value instead of an unevaluated thunk. treesum (Leaf a) = return a treesum (Node a l r) = do futl future (treesum l) futr future (treesum r) let result = (a + futl + futr) in seq result (return result) Fig. 3. Parallel tree sum with implicit futures It is also possible to implement recursive futures, i.e. at the moment of creation of a future its corresponding code is applied to the future. Fig. 4 shows

4 4 David Sabel the implementation of recursive futures. Reading from the MVar which will store the result of the concurrent computation is performed (but delayed using unsafeinterleaveio) before the concurrent computation is started, i.e. the name of future is known for the concurrent computation and thus can be used as an argument for the code. If a recursive future gets triggered we use the evaluate-function to trigger the takemvar-call recursivefuture :: (a IO a) IO a recursivefuture code = do ack newemptymvar res unsafeinterleaveio (takemvar ack) thread forkio (code res >>= putmvar ack) unsafeinterleaveio (do res evaluate res killthread thread return res ) Fig. 4. Implementation of recursive futures 3 Other Kinds of Futures The futures presented so far are sometimes not sufficient, since their evaluation is not controlled. There is no guarantee, that the futures are evaluated. Like the primitive forkio all concurrent evaluations of futures are abruptly killed if the main thread of the program stops. One may want to have futures with a guarantee that their evaluation is finished before the main program can terminate. A brute-force method is to add a call seqlist [f 1,..., f m] as a last IO-action to the program, where f 1,..., f n are all introduced futures, f i = seq f i () for all i, and seqlist sequentially enforces the evaluation of all elements of a list, i.e. it is defined by seqlist [] = return () seqlist (x:xs) = seq x (seqlist xs) But, again the programmer is responsible to add all futures in this list, which is annoying. We present another implementation which adds a global manager to keep track of the introduced futures an ensures the evaluation of all (strict) futures before terminating the main thread. From the programmer s view this is easy to use. All what is necessary is to add a global wrapper function withfuturesdo around the main function. I.e., instead of writing main = code, one writes main = withfuturesdo code. The global manager is an MVar which contains a list of trivial unit-tupels. In Fig. 5 the manager and the operations newmanager which creates an MVar containing the empty list, register, which registers a future l, by adding (seq l ()) to the list (here seq is only used to ensure correct typing, since

5 Implementing Concurrent Futures in Concurrent Haskell 5 we cannot add l directly), and synchronizeman which ensures the evaluation of all futures stored in the list. type Manager = MVar [()] newmanager :: IO Manager newmanager = newmvar [] register :: a Manager IO () register l man = do list takemvar man putmvar man ((seq l ()):list) synchronizeman :: Manager IO () synchronizeman man = do list takemvar man seqlist list Fig. 5. Implementation of the manager The implementation of strict futures (with a non-recursive variant strictfuture and a recursive version strictrecursivefuture) and the global wrapper function is shown in Fig. 6, where strict futures are implemented like futures where in addition a call to the register-function is performed. We aso create a global variable globalman for the manager using unsafeperformio. It is also possible to introduce another kind of futures, which may be called lazy futures or suspended futures. The desired behavior of those futures is that there is no computation performed unless their value is needed (if their value is needed, then the futures behave like strict futures). Their implementation is really easy using another unsafeinterleaveio-call: lazyfuture :: IO a IO a lazyfuture code = unsafeinterleaveio (strictfuture code) lazyrecursivefuture :: (a IO a) IO a lazyrecursivefuture code = unsafeinterleaveio (strictrecursivefuture code) References Pey01. Simon Peyton Jones. Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell. In Ralf Steinbruggen Tony Hoare, Manfred Broy, editor, Engineering theories of software construction, pages IOS-Press, Presented at the 2000 Marktoberdorf Summer School.

6 6 David Sabel withfuturesdo :: IO () IO () withfuturesdo code = do code synchronizeman globalman globalman = unsafeperformio newmanager strictfuture :: IO a IO a strictfuture code = do fut future code register fut globalman return fut strictrecursivefuture :: (a IO a) IO a strictrecursivefuture code = do fut recursivefuture code register fut globalman return fut Fig. 6. The global wrapper and the implementation of strict futures PGF96. S. Peyton Jones, A. Gordon, and S. Finne. Concurrent Haskell. In Proc. 23th Principles of Programming Languages, 1996.