I would use a simple variation of the producer-consumer pattern. You'd have two theads, a producer and a consumer, that share an integer variable. The producer would have a System.Threading.Timer
that fired every second, at which time it would Interlocked.Increment
the variable and call the consumer. The consumer logic repeatedly checks the feed and Interlocked.Decrement
the counter, while the counter is greater than zero. The consumer logic would be protected by a Monitor.TryEnter
which would handle re-entrancy. Here's sample code.
public static FeedCheck{
int _count = 0;
static object _consumingSync = new object();
static Threading.Timer _produceTimer;
private static void Consume() {
if (Monitor.TryEnter(_consumingSync)) {
while(_count > 0) {
// check feed
Interlocked.Decrement(ref _count);
}
}
}
private static void Produce() {
Interlocked.Increment(ref _count);
Consume();
}
public static void Start() {
// small risk of race condition here, but not necessarily
// be bad if multiple Timers existed for a moment, since only
// the last one will survive.
if (_produceTimer == null) {
_produceTimer = new Threading.Timer(
_ => FeedCheck.Produce(), null, 0, 1000
);
}
}
}
Usage:
FeedCheck.Start();
A good resource on .NET Threading (besides the MSDN Library stuff) is Jon Skeet's documentation, which includes this example of producer-consumer under "More Monitor
methods".
By the way, a true producer-consumer pattern revolves around a collection of work data, with one or more threads producing work by adding data to that collection, while one or more other threads consumer work by removing data from that collection. In our variation above, the "work data" is merely a count of the number of times we need to immediately check the feed.
(Another way to do it, instead of having the timer callback call Consume, is for the timer callback to lock and pulse a Monitor
that Consume waits on. In that case, Consume has an infinite loop, like while(true)
, which you kick off one time in its own thread. Therefore there is no need to support re-entrancy with the call to Monitor.TryEnter
.)