How does BackgroundTimer differ from ThreadPoolTimer?

Oct 6, 2012 at 2:47 AM

BackgroundTimer seems to provide the same functionality provided by ThreadPoolTimer, only with less friendly creation syntax.  Is it substantially better or is that just an oversight?  I was actually considering writing CreateTimer and CreatePeriodicTimer extension methods for DispatcherTimer.  Am I missing some aspect as to why this is preferable?

Coordinator
Oct 6, 2012 at 3:54 AM

It was written in response to this SO question: Controlled non UI timer in metro app (.NET). The purpose was to have ticks on a background thread and have the same API as the DispatcherTimer. It also has an option to self adjust a bit to have an average frequency closer to what you would expect given the configured Interval. That said I was not aware of the ThreadPoolTimer, so it is possible it makes more sense to use that one. It is a bit strange that the two timers we get have different APIs though, so perhaps that is one case where using the BackgroundTimer makes a little bit of sense.

 

Oct 6, 2012 at 4:19 AM
xyzzer wrote:

It was written in response to this SO question: Controlled non UI timer in metro app (.NET). The purpose was to have ticks on a background thread and have the same API as the DispatcherTimer. It also has an option to self adjust a bit to have an average frequency closer to what you would expect given the configured Interval. That said I was not aware of the ThreadPoolTimer, so it is possible it makes more sense to use that one. It is a bit strange that the two timers we get have different APIs though, so perhaps that is one case where using the BackgroundTimer makes a little bit of sense.

Oh, I see what the guy's getting at; a DispatcherTimer can be stopped and resumed, have its interval length changed, and have its tick handlers modified, but a ThreadPoolTimer is basically invariant after creation beyond cancelling.

It would be possible rewrite BackgroundTimer to use ThreadPoolTimer on an implementation level, but it's not clear that it'd make any difference on a performance or memory usage level, so it's probably not worth it.  I'll look into making writing ThreadPoolTimer-style constructors for DispatcherTimer, though, and submit the source to you when I get a chance.

Oct 6, 2012 at 5:38 AM

Okay, I did it.