mail archive The Haskell Cafe
haskell-cafe.haskell.org
(List home) (Recent threads) (38 other Haskell lists)
Subscription Options
- RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
- Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
- Moderate traffic list: up to 30 messages per day
- This list contains about 107,330 messages, beginning Oct 2000
- 19 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no
Parallel cooperative multithreading?
Ad
Has anyone ever worked on implementing something like this in Haskell? http://www.cs.hmc.edu/~stone/papers/ocm-unpub... 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.
-RyanOn Tue, May 22, 2012 at 9:55 AM, Benjamin Ylvisaker
wrote:
> Has anyone ever worked on implementing something like this in Haskell?
>
> http://www.cs.hmc.edu/~stone/papers/ocm-unpub...
>
> 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
>
> http://www.haskell.org/mailman/listinfo/haske...
>
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-unpub...
>
> 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 writes: > 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