System.Threading.Timer Wrapper

Question

I think it is curious that every timer-driven event requires a new instance of a timer object.  It seems it would make more sense to have a "timer event-collection singleton" that stores a SortedDictionary having TimeSpan keys, and <delegate,object> pair values.  The timer would only act on the first item in the SortedDictionary, and when it does, it automatically re-programs itself with the next item in the SortedDictionary.  The delegate it invokes would take an object parameter (to behave like APM parameter passing).

There are other features that could be added (such as adding another index so that event requests can be cancelled), but I'm just curious if (1) has somebody already made something like this and (2) is there any particular reason why this is a bad idea?  It seems so simple, and seemingly useful, I'm not sure why it isn't already part of the BCL.

---

-Brent Arias

Answer 1

1) No, I never did anything like that for the simple reason that I never found a practical application for something like that. I don't doubt you may have one, but I don't see it as something commonly needed.

2) As somebody says, every feature starts with -100 points... when something is both relatively easy to implement and is not presumably going to be used by a vast majority, I think that the chances that it would become part of the BCL are extremely slim (otherwise we would end up with a multi GB framework download).

Just my 2 cents
--mc

Answer 2

Ok, I suppose an important implication from your thoughts - is that there isn't necessarily something inherently wrong with the idea.  An example of "inherently wrong" would be if all timer instances are implemented in the BCL to access an internal timer singleton.  If that were true, then I would be creating a redundant mechanism.

So if the timer instances I'm creating are sometimes bursting at a rate of a hundred new timers per second, then it seems the wrapper I'm describing would be an ok thing to do.  Someone might question why I would create so many timers so quickly, but that is a different topic...

---

-Brent Arias

Answer 3

Seems like a good class for your snippet cache, but not for inclusion in the framework.  Very similar to a state machine, which I don't think has ever been standardized.

Answer 4

separate instance, something screwed up in the thread, it died/hang itself.

1 basket 1 egg. 100 eggs. 10 baskets dropped, 90 still there.

a all-instances-in-one-thingy, 1 of them screwed up a bit, even causing like delay for 2 seconds, it can affect the other "innocent" instances in it.

1 basket 100 eggs, 1 basket drop, you got a basket full of liquid to toast.

Answer 5

separate instance, something screwed up in the thread, it died/hang itself.

1 basket 1 egg. 100 eggs. 10 baskets dropped, 90 still there.

a all-instances-in-one-thingy, 1 of them screwed up a bit, even causing like delay for 2 seconds, it can affect the other "innocent" instances in it.

1 basket 100 eggs, 1 basket drop, you got a basket full of liquid to toast.

I assume that System.Threading.Timer uses the BCL threadpool for events it launches, which means it won't matter if the "basket is dropped."  Indeed, the proposed wrapper would re-program itself with the next event *before* it invokes a callback for the current event (using the worker thread).

But perhaps you are saying that System.Threading.Timer does not use the threadpool?  That instead it has exactly one fore-ground thread?  If that were true, then it might indeed be a probem.

---

-Brent Arias

Answer 6

Hello Brent,

 

It’s really an interesting topic.  Based on MSDN document of System.Threading.Timer:

 

“The callback method executed by the timer should be reentrant, because it is called on ThreadPool threads. The callback can be executed simultaneously on two thread pool threads if the timer interval is less than the time required to execute the callback, or if all thread pool threads are in use and the callback is queued multiple times.”

 

So I agree with you that the System.Threading.Timer uses the BCL threadpool for events it launches. 

 

I would recommend you create a suggestion at Microsoft Connect to report this to the product team.  We may get more detailed information from the product team.   I am also looking forward to other community members idea on this topic.  

 

Have a nice day, all!

 

 

Best Regards,
Lingzhi Sun

MSDN Subscriber Support in Forum

If you have any feedback on our support, please contact [e-mail]

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 7

Hi Brent,

I'm writing to check the issue status, did get any suggestion from Microsoft Connect ? Please feel free to let us know if you have any concern.

---

Sincerely,
Eric
MSDN Subscriber Support in Forum
If you have any feedback of our support, please contact [e-mail].
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.