There is nothing absolutely continuous and asynchronous at the same time. When you want to monitor a thread, you should synchronize your calling thread and another thread. The minimal synchronization facility can be a lock:
http://msdn.microsoft.com/en-us/library/c5kehkcz.aspx[
^].
It would mean that threads sometimes wait for each other a bit, which is already non-continuous.
Now, if you want pull processing (monitoring is done periodically by the initiative of the calling thread, not a thread being monitoring), this solution is inherently ineffective. This is important thing to understand:
http://en.wikipedia.org/wiki/Pull_technology[
^],
http://en.wikipedia.org/wiki/Push_technology[
^].
Push technology is much better. In your case, it is implemented in the following way: a calling (monitoring) thread is subscribed to the thread to be monitored. Essentially, it adds an event handler to an invocation list of some event instance of the code related to the thread to be monitored. Then this thread invokes this event (or some of the set of such notification events), only when something is essentially changed in its state. For such code, it's important to have a thread wrapper. Please see my past answer showing such a wrapper with an events:
MultiThreading in C#[
^].
See also my other answers on the topic:
Change parameters of thread (producer) after it is started[
^],
How to pass ref parameter to the thread[
^].
The example with the lock referenced above shows the pull approach. The lock is all you need for thread polling, but this is not a good way. If you poll it periodically, you waste performance. If you do it frequently, you do a lot of cycles in vain, when nothing really happens. In all cases, you miss some events, especially with non-frequent polling, and have some probability to miss them regardless of timing and priorities. Polling, push processing is bad.
There is one problem you have to address. The monitoring thread should responsively handle the events. For example, if it should show some monitoring results in UI, you cannot do it in the thread invoking the event, because it would be a thread to be monitored, not a UI thread. Hence, a UI thread invocation mechanism should be used. This is just one example of handling thread notification results. Please see my past answers on the problem:
Control.Invoke() vs. Control.BeginInvoke()[
^],
Problem with Treeview Scanner And MD5[
^].
—SA
Submit an article or tip