[Haskell-cafe] 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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
Thank you all, I've used a simple IORef and that did the trick. JP 2012/2/8 Edward Amsden : > 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 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 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 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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
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 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
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 > 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 > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
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 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 >> >> 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
Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
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 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 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 >>> >>> 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
