Concurrency strategy for 2 threads and rare events

JP Moresmau

8 Feb 2012 8 Feb '12

11:04 a.m.

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/

Show replies by date

Erik Hesselink

8 Feb 8 Feb

11:11 a.m.

New subject: 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

Yves Parès

1:35 p.m.

New subject: 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

JP Moresmau

2:45 p.m.

New subject: 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/

Edward Amsden

3:26 p.m.

New subject: 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

JP Moresmau

15 Feb 15 Feb

1:10 p.m.

New subject: 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/

4845

Age (days ago)

4852

Last active (days ago)

List overview

Download

5 comments

4 participants

participants (4)

Edward Amsden
Erik Hesselink
JP Moresmau
Yves Parès