views:

116

answers:

4

hey guys, I'm totally inexperienced in terms of threads, so here's my question:

How do threads work within an instance of an object, in particular, I'm working on a Windows Service.

So, my Service is basically an instance of an Object right?

So, say I have a System.Timers.Timer in my Service, and that fires an ElapsedEventHandler every 10 seconds.

Say each operation in the Timer event handler will take 1 minute to complete.

Does each event get handled by a different thread?

If so, how do the properties of my object react to this? Are properties shared across threads?

What is the thread limit? do they run out? and if so, what happens when the Timer Event fires, and all the threads are taken up?

thank so much, I particularly interested in how the properties are shared across threads?? if thats what happens.

cheers!

+4  A: 

Jon Skeet has a few introductory pages on threading basics, here (note there are 17 separate pages of topics here).

Does each event get handled by a different thread?

That depends on the specific timer, but that would be a safe (i.e. worst-case) assumption

Are properties shared across threads?

Yes; there is no protection from multiple threads accessing your data unless you write it yourself, either with [MethodImpl(MethodImplOptions.Synchronized)] (to make a method synchronized), or with a construct such as lock. The only exception to this is static fields marked with the special attribute [ThreadStatic], which then has one static field per thread.

What is the thread limit? do they run out? and if so, what happens when the Timer Event fires, and all the threads are taken up?

Limited in part by the OS resources, and in part by whether they are "regular" threads or pool threads. But if you are using enough for this to be an issue, you have too many threads. If there aren't enough resources to start a thread, either it'll start failing (regular threads), or the work will simply pile up, waiting for more availability (pool threads). It is entirely possible to saturate the thread pool and deadlock everything. Avoid too many threads, basically.

Marc Gravell
+1  A: 

System.Timers.Timer will use a thread pool thread each time the Elapsed triggers, i dont know if there is a maximum but the thread pool should handle this in a good way i hope.. but running to many threads at the same time is not recommended, the cpu has to change thread all the time and that has it's costs.

Properties are shared across diffrent threads but thay aren't thread safe if you dont make them thread safe.

Petoj
+2  A: 

This is a fairly complex topic, and I'd suggest spending some time working through the extensive Threading doco on msdn here: http://msdn.microsoft.com/en-us/library/3e8s7xdd.aspx

Each timer elapsed event is handled on a separate thread (and the threads come from the ThreadPool which controls thread availability). Objects and properties are shared across threads, and it is your responsibility to lock critical sections. I use the static Interlocked class for lightweight locking. There's plenty of examples if you google for it.

AndrewS
+1  A: 

Yes, every time the event fires it gets handled on a threadpool thread. Also, there is only one instance of your object in memory, so the threads will all share access to the same variables.

It would be a really good idea to read up on threading and the timer, maybe look at some examples, because otherwise you may end up pulling out most of your hair in the process of getting things to work reliably.

Note: I hope that your handler does not take 1 minute on each 10 second event fire, because then your number of running threads will grow by 5 every minute and never come down again... you can't keep doing more and more work simultaneously.

jerryjvl
haha, no no, the 10 secs/1 minute thing was just for argument sakes. Currently a static bool prevents any work being carried on in the handler, if one task is already happening. i just wanted to understand it more. So, I assume that once the scope leaves that Event Handler, that particular thread is released right?
andy
If you are going to keep it this way i would suggest skip the timer and spawn your own thread that loops and checks if there is any thing to do and then carry out the work on that thread, there is no need to make things more complicated then thay have to be! this would give you 1 thread and no timer...
Petoj
@andy: after the event handler completes, the thread is returned to the threadpool... (it does not terminate as such though, although that won't make any practical difference to you)
jerryjvl
@Petoj, with your "spawn your own thread" solution, are you suggesting a Thread.Sleep during each iteration? That's more complicated and error-prone than a timer. Timers are easier to clean-up, for one thing.
MattH