Timer or threading Q

[Guest]

Yello,

Quick Q:
I created a windows service that changes some data every (approx) 1sec,
but currently it is using a loop on a separate thread that uses
Thread.Sleep(1000).
Is that bad programming tecnique? Should I be using a timer instead? Is there
any good advantages to the way it is done?

A side Q:
I am currently working with the newest version of .net. In the previous
version,
I was running in to trouble using the System.Threading.Timer class. It would
only run for a certain number of call backs then would fail to run anymore.
I fixed that problem by going to a server timer. I haven't a clue why it kept
failing, and I dont know if it does such in the newer version. Can anyone
shead
some light on the matter??

Thanks in advance for any and all help.

 

[Nicholas Paldino [.NET/C# MVP]]

Without seeing how you are using the timer, I can't say why it would or
would not work. However, I do agree that using the timer is better than
creating a thread and then putting it to sleep every second.

Hope this helps.

 

[MJB]

I had similar problems with the timer object so I changed my code to use
a while loop with a sleep delay, which was much more reliable. I'm not
sure if the timer has been modified in .Net 2.0 or not. I never did
figure out why the timer would stop firing.

Regarding your service...it's hard to say if it's bad technique. If you
don't care exactly when the timer fires, just that it fires every 5
seconds than what your doing is fine IMO. Good luck.

 

[Jon Skeet [C# MVP]]

Quick Q:
I created a windows service that changes some data every (approx) 1sec,
but currently it is using a loop on a separate thread that uses
Thread.Sleep(1000).
Is that bad programming tecnique? Should I be using a timer instead? Is there
any good advantages to the way it is done?

Well, it's simple. That's a pretty strong advantage in my view. So long
as you make sure that you keep going in the face of any exceptions (if
you want to), it seems an entirely reasonable way of working to me.

A side Q:
I am currently working with the newest version of .net. In the previous
version,
I was running in to trouble using the System.Threading.Timer class. It would
only run for a certain number of call backs then would fail to run anymore.
I fixed that problem by going to a server timer. I haven't a clue why it kept
failing, and I dont know if it does such in the newer version. Can anyone
shead some light on the matter??

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

 

[Jon Skeet [C# MVP]]

Without seeing how you are using the timer, I can't say why it would or
would not work. However, I do agree that using the timer is better than
creating a thread and then putting it to sleep every second.

Why, out of interest? Using a sleep seems inherently simpler to me. I
would find it easier to debug, too. There are times when timers are
useful, but in this case I think the sleep solution sounds like the
best one.

 

[Willy Denoyette [MVP]]

Yello,

Quick Q:
I created a windows service that changes some data every (approx) 1sec,
but currently it is using a loop on a separate thread that uses
Thread.Sleep(1000).
Is that bad programming tecnique? Should I be using a timer instead? Is
there
any good advantages to the way it is done?

A side Q:
I am currently working with the newest version of .net. In the previous
version,
I was running in to trouble using the System.Threading.Timer class. It
would
only run for a certain number of call backs then would fail to run
anymore.
I fixed that problem by going to a server timer. I haven't a clue why it
kept
failing, and I dont know if it does such in the newer version. Can anyone
shead
some light on the matter??

Thanks in advance for any and all help.

IMO it's the right choice:
It's simple, and it doesn't waste any more resources like timers.
Of course this doesn't solve the issue with the timer which should work as
well, in general this is due to the fact that you aren't holding a reference
to the timer or it's callback, that means that the timer or the callback
will be destroyed when the GC comes along, not sure though, only debugging
will tell

Willy.

 

[Kevin Spencer]

Why, out of interest? Using a sleep seems inherently simpler to me. I

would find it easier to debug, too. There are times when timers are
useful, but in this case I think the sleep solution sounds like the
best one.

The only reason I can think of for using a timer is when you need to perform
work at a specific timed interval. If the timing isn't critical, putting the
thread to sleep would work fine.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

 

[Jon Skeet [C# MVP]]

The only reason I can think of for using a timer is when you need to perform
work at a specific timed interval. If the timing isn't critical, putting the
thread to sleep would work fine.

Yes - although even if you wanted to do it at intervals, you could
always sleep for a variable length of time instead of always waiting
for a second. (Work out when you should next fire, and subtract the
current time.)

 

[Nicholas Paldino [.NET/C# MVP]]

Personally, I find the logic and semantics to be more clear when using a
timer. But that's just me. The idea of manually spawning a thread and
putting it to sleep, when there is something that does the same thing is a
bit redundant.