Concurrency strategy for 2 threads and rare events
Hello, I'm wondering what's the best strategy to use in the following scenario: - 2 threads - One perform some work that will take time, possibly go on forever - Another waits for user input (like commands from the keyboard) that affects thread 1 (causing it to stop, in the simplest case) I've read a bit on MVar and channels, but they seem to be a lot for cases where the reading thread block for input. In my case, I expect to have "something" that thread 2 updates when an event occur, and thread 1 checks it regularly. So thread 1 should not block, but should check "is there something" and there is, act on it, otherwise continue doing what it was currently doing. I suppose I could just tryTakeMVar on a MVar, but is there something more adapted to my needs? Thanks! -- JP Moresmau http://jpmoresmau.blogspot.com/
You could use throwTo to raise an exception in the thread you want to stop. Otherwise, having some variable (IORef, TVar, MVar) that the long running thread occasionally checks seems like a good solution. Erik On Wed, Feb 8, 2012 at 17:04, JP Moresmau <jpmoresmau@gmail.com> wrote:
Hello, I'm wondering what's the best strategy to use in the following scenario: - 2 threads - One perform some work that will take time, possibly go on forever - Another waits for user input (like commands from the keyboard) that affects thread 1 (causing it to stop, in the simplest case)
I've read a bit on MVar and channels, but they seem to be a lot for cases where the reading thread block for input. In my case, I expect to have "something" that thread 2 updates when an event occur, and thread 1 checks it regularly. So thread 1 should not block, but should check "is there something" and there is, act on it, otherwise continue doing what it was currently doing. I suppose I could just tryTakeMVar on a MVar, but is there something more adapted to my needs?
Thanks!
-- JP Moresmau http://jpmoresmau.blogspot.com/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Why do you think it's a lot? MVar are a teeny tiny and convenient primitive of communication, and I don't see why they wouldn't suit your need. Sure a throwTo would do the trick... But they're is "do the trick" and "do the job", you see? Using STM and TVars *would* be kind of overkill. 2012/2/8 JP Moresmau <jpmoresmau@gmail.com>
Hello, I'm wondering what's the best strategy to use in the following scenario: - 2 threads - One perform some work that will take time, possibly go on forever - Another waits for user input (like commands from the keyboard) that affects thread 1 (causing it to stop, in the simplest case)
I've read a bit on MVar and channels, but they seem to be a lot for cases where the reading thread block for input. In my case, I expect to have "something" that thread 2 updates when an event occur, and thread 1 checks it regularly. So thread 1 should not block, but should check "is there something" and there is, act on it, otherwise continue doing what it was currently doing. I suppose I could just tryTakeMVar on a MVar, but is there something more adapted to my needs?
Thanks!
-- JP Moresmau http://jpmoresmau.blogspot.com/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
No, I meant they seem to be mainly for the use case where the reading thread blocks for more input, and maybe there's a simpler/more efficient way to quickly check if an event has occurred, that's all. If there isn't then a MVar it will be. JP On Wed, Feb 8, 2012 at 7:35 PM, Yves Parès <yves.pares@gmail.com> wrote:
Why do you think it's a lot? MVar are a teeny tiny and convenient primitive of communication, and I don't see why they wouldn't suit your need. Sure a throwTo would do the trick... But they're is "do the trick" and "do the job", you see?
Using STM and TVars *would* be kind of overkill.
2012/2/8 JP Moresmau <jpmoresmau@gmail.com>
Hello, I'm wondering what's the best strategy to use in the following scenario: - 2 threads - One perform some work that will take time, possibly go on forever - Another waits for user input (like commands from the keyboard) that affects thread 1 (causing it to stop, in the simplest case)
I've read a bit on MVar and channels, but they seem to be a lot for cases where the reading thread block for input. In my case, I expect to have "something" that thread 2 updates when an event occur, and thread 1 checks it regularly. So thread 1 should not block, but should check "is there something" and there is, act on it, otherwise continue doing what it was currently doing. I suppose I could just tryTakeMVar on a MVar, but is there something more adapted to my needs?
Thanks!
-- JP Moresmau http://jpmoresmau.blogspot.com/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- JP Moresmau http://jpmoresmau.blogspot.com/
If you only need one structure for communication (e.g. neither thread needs to lock multiple things) you might consider using an IORef, and writing/polling it with atomicModifyIORef. It's cheaper than an MVar for the case where you don't need to lock multiple threads. On Wed, Feb 8, 2012 at 2:45 PM, JP Moresmau <jpmoresmau@gmail.com> wrote:
No, I meant they seem to be mainly for the use case where the reading thread blocks for more input, and maybe there's a simpler/more efficient way to quickly check if an event has occurred, that's all. If there isn't then a MVar it will be.
JP
On Wed, Feb 8, 2012 at 7:35 PM, Yves Parès <yves.pares@gmail.com> wrote:
Why do you think it's a lot? MVar are a teeny tiny and convenient primitive of communication, and I don't see why they wouldn't suit your need. Sure a throwTo would do the trick... But they're is "do the trick" and "do the job", you see?
Using STM and TVars *would* be kind of overkill.
2012/2/8 JP Moresmau <jpmoresmau@gmail.com>
Hello, I'm wondering what's the best strategy to use in the following scenario: - 2 threads - One perform some work that will take time, possibly go on forever - Another waits for user input (like commands from the keyboard) that affects thread 1 (causing it to stop, in the simplest case)
I've read a bit on MVar and channels, but they seem to be a lot for cases where the reading thread block for input. In my case, I expect to have "something" that thread 2 updates when an event occur, and thread 1 checks it regularly. So thread 1 should not block, but should check "is there something" and there is, act on it, otherwise continue doing what it was currently doing. I suppose I could just tryTakeMVar on a MVar, but is there something more adapted to my needs?
Thanks!
-- JP Moresmau http://jpmoresmau.blogspot.com/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- JP Moresmau http://jpmoresmau.blogspot.com/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Edward Amsden Student Computer Science Rochester Institute of Technology www.edwardamsden.com
Thank you all, I've used a simple IORef and that did the trick. JP 2012/2/8 Edward Amsden <eca7215@cs.rit.edu>:
If you only need one structure for communication (e.g. neither thread needs to lock multiple things) you might consider using an IORef, and writing/polling it with atomicModifyIORef. It's cheaper than an MVar for the case where you don't need to lock multiple threads.
On Wed, Feb 8, 2012 at 2:45 PM, JP Moresmau <jpmoresmau@gmail.com> wrote:
No, I meant they seem to be mainly for the use case where the reading thread blocks for more input, and maybe there's a simpler/more efficient way to quickly check if an event has occurred, that's all. If there isn't then a MVar it will be.
JP
On Wed, Feb 8, 2012 at 7:35 PM, Yves Parès <yves.pares@gmail.com> wrote:
Why do you think it's a lot? MVar are a teeny tiny and convenient primitive of communication, and I don't see why they wouldn't suit your need. Sure a throwTo would do the trick... But they're is "do the trick" and "do the job", you see?
Using STM and TVars *would* be kind of overkill.
2012/2/8 JP Moresmau <jpmoresmau@gmail.com>
Hello, I'm wondering what's the best strategy to use in the following scenario: - 2 threads - One perform some work that will take time, possibly go on forever - Another waits for user input (like commands from the keyboard) that affects thread 1 (causing it to stop, in the simplest case)
I've read a bit on MVar and channels, but they seem to be a lot for cases where the reading thread block for input. In my case, I expect to have "something" that thread 2 updates when an event occur, and thread 1 checks it regularly. So thread 1 should not block, but should check "is there something" and there is, act on it, otherwise continue doing what it was currently doing. I suppose I could just tryTakeMVar on a MVar, but is there something more adapted to my needs?
Thanks!
-- JP Moresmau http://jpmoresmau.blogspot.com/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- JP Moresmau http://jpmoresmau.blogspot.com/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Edward Amsden Student Computer Science Rochester Institute of Technology www.edwardamsden.com
-- JP Moresmau http://jpmoresmau.blogspot.com/
participants (4)
-
Edward Amsden -
Erik Hesselink -
JP Moresmau -
Yves Parès