Parallel cooperative multithreading?
Has anyone ever worked on implementing something like this in Haskell? http://www.cs.hmc.edu/~stone/papers/ocm-unpublished.pdf The outline of the idea: - Concurrent programming is really hard with the popular frameworks today. - For most purposes parallel programming is hard, in some part because it requires concurrent programming. Of course there are attempts to do non-concurrent parallel programming, but I hope it's not too controversial to say that such frameworks are still on the fringe. - Cooperative concurrency is way easier than preemptive concurrency because between invocations of pause/yield/wait, sequential reasoning works. - Historically, cooperative concurrency only worked on a single processors, because running threads in parallel would break the atomicity of sequential blocks (between invocations of p/y/w). - Researchers have been poring tons of effort into efficiently running blocks of code atomically. - Hey, we can do parallel cooperative multithreading! The paper discusses implementations in Lua, C++ and C, but I think Haskell could be an awesome substrate for such a framework. Has anyone thought about this? Ben
Personally, I think cooperative concurrency is making a big comeback.
Especially in a compiler-supporting form that relies on limited CPS
(continuation-passing-style) transformation. There are server and web
services applications that motivate it (i.e. in Scala, F# async work flows).
In Haskell we've got ContT for capturing the continuation of one
computation (and yielding to another). Monad-par is an example of a
framework based on ContT in which tasks cooperatively yield control
whenever their desired input data is not yet available.
-Ryan
On Tue, May 22, 2012 at 9:55 AM, Benjamin Ylvisaker
Has anyone ever worked on implementing something like this in Haskell?
http://www.cs.hmc.edu/~stone/papers/ocm-unpublished.pdf
The outline of the idea:
- Concurrent programming is really hard with the popular frameworks today. - For most purposes parallel programming is hard, in some part because it requires concurrent programming. Of course there are attempts to do non-concurrent parallel programming, but I hope it's not too controversial to say that such frameworks are still on the fringe. - Cooperative concurrency is way easier than preemptive concurrency because between invocations of pause/yield/wait, sequential reasoning works. - Historically, cooperative concurrency only worked on a single processors, because running threads in parallel would break the atomicity of sequential blocks (between invocations of p/y/w). - Researchers have been poring tons of effort into efficiently running blocks of code atomically. - Hey, we can do parallel cooperative multithreading!
The paper discusses implementations in Lua, C++ and C, but I think Haskell could be an awesome substrate for such a framework. Has anyone thought about this?
Ben
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On 12-05-22 09:55 AM, Benjamin Ylvisaker wrote:
Has anyone ever worked on implementing something like this in Haskell?
http://www.cs.hmc.edu/~stone/papers/ocm-unpublished.pdf
The outline of the idea:
- Concurrent programming is really hard with the popular frameworks today. - For most purposes parallel programming is hard, in some part because it requires concurrent programming. Of course there are attempts to do non-concurrent parallel programming, but I hope it's not too controversial to say that such frameworks are still on the fringe. - Cooperative concurrency is way easier than preemptive concurrency because between invocations of pause/yield/wait, sequential reasoning works. - Historically, cooperative concurrency only worked on a single processors, because running threads in parallel would break the atomicity of sequential blocks (between invocations of p/y/w). - Researchers have been poring tons of effort into efficiently running blocks of code atomically. - Hey, we can do parallel cooperative multithreading!
The paper discusses implementations in Lua, C++ and C, but I think Haskell could be an awesome substrate for such a framework. Has anyone thought about this?
I have, which is why the monad-coroutine library comes with support for running multiple coroutines in parallel, meaning that their steps are run in parallel rather than interleaved. Unfortunately, I never managed to extract any actual speedup out of this feature in my tests.
Benjamin Ylvisaker
The paper discusses implementations in Lua, C++ and C, but I think Haskell could be an awesome substrate for such a framework. Has anyone thought about this?
I'm not convinced this will be better than using STM - the critique against STM seems (as always) not to apply to implementations where transactional data are segregated by the type system. I'm not sure about the non-composability of retry and orElse that the authors refer to, anybody know? -k -- If I haven't seen further, it is by standing in the footprints of giants
participants (4)
-
Benjamin Ylvisaker -
Ketil Malde -
Mario Blažević -
Ryan Newton