how to determine each thread is already finished to run

Hello All,

I have 2 threads that willl runnning in a timer_tick event
how to determine each thread is already finished to run

I want to try IsAlive .. but I want to make sure.. does IsAlive property will return false when the thread completely finished ?

or any other idea or suggestion?

Thanks

Code:

---

Thread t1;
Thread t2;
..
..
..
private void runningTimer_Tick(object sender, EventArgs e)
{
_second++;

if (_second >= SECOND_HOUR)
 {
  if (!t1.IsAlive && !t2.IsAlive)
  {
    _second = 0;
    t1.Start();
    }
  }
  else
  {
    if (!t2.IsAlive && !t1.IsAlive)
    {
    t2.Start();
    }
  }
}

---

This looks like an incorrect use of threading - what are you trying to achieve that you think you need threading for?

I want to send SMS to some recipients, t1 is to send birthday SMS and t2 is send SMS notification ..
since the SMS is a serial device so only one thread can access the device at the same time.

any suggestion?

Don't use multi-threading, and call it from the main UI thread. I can't believe it's going to take that long to send the SMS is it?

If you're worried about accidentally calling it from multiple threads even then, you can use the synchronisation primitives inside your SMS abstraction (you have encapsulated the SMS service behind some kind of interface*, right?) to prevent execution of the critical block of code simultaneously.

* Not as in the keyword interface, but the layman's meaning - could equally be a class, a method, or some other kind of abstraction.

best practice here is to NOT do threading because the task is not a time consuming task. Threading is expensive and should only be used in time consuming tasks, rightly so said by evil giraffe.

the IsAlive property does however tell you if the thread has completed but you can have a problem here. what if the Thread was aborted or stopped in a non normal way? (i.e an error occured) - you would still get true for the property value.

the best thing here would be to use Auto or ManualResetEvents and also WaitHandle.WaitAll a collection of them and wait until all the signals have been indicated/set that the thread has finished doing the task at hand (based upon your business logic rules)

http://msdn.microsoft.com/en-us/libr...esetevent.aspx
http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx

but again, we are over doing work because for a small task you are describing, does not require to be threaded.

Would the ThreadPool suit your needs?

You could set the max workers to 1 and queue all the messages.
Alternately you could just let the thread process a queue (as in collection).

again.... for a task that is NOT time consuming - why thread?

Well if I understand correctly the messages are being sent through a phone connected as a serial device.
This can take a second or two for each message depending on signal strength etc.
And there could be multiple messages to be sent.

So in terms of keeping the UI thread responsive it's not a bad idea.

actually, it still is. a second or two is NOT a long running task AT ALL. in addition, keeping the UI responsive does not necessarily mean spin up another or multiple threads (depends on the context though!)

what you want to do, is batch them up, then send them on a background thread. not a thread per message.

the OP's code snippet for a timer and monitoring 2 threads is also... not entirely efficient and would probably cause more problems. best thing is to batch up the messages into a list, then on the timer, check to see if there are messages to be sent and if so - spin up the thread and send the messages from that thread but making sure that you are using thread safe techniques if you are "inspecting" the list from outside the thread.

Alright, I can agree on that.