C# Development

Using Thread.Join to Ensure a Worker Thread Has Exited

2004-06-11T08:43:00.000-07:00

Using threads is difficult. A developers coding complexity increases dramatically. Issues such as reentrance, deadlock and race conditions are difficult to detect and avoid. Creating, using and ending threads all require careful implementation of managing thread lifetimes.

In this discussion, we look at one way a thread can synchronize itself with another thread waiting for it to complete. This technique can be used as part of an orderly shutdown of worker threads. The System.Threading.Thread class has an instance member called Join that can provide this type of functionality. Join provides several overloads. Using Join is not difficult. But, using it wisely is.

For the simple Join case, we can call the Join overload that takes no arguments. This call will block until the thread being joined to has ended. The call is simple, but dangerous. Consider when this joined thread never ends! The calling thread would then be hung and would not be able to continue until some other thread interrupted or aborted it. This special case is difficult to code and best avoided if possible.

Thankfully Join also provides overloads that require a timeout parameter. Their use is preferred. These overloads take either a millisecond or a TimeSpan timeout. They both return a bool that is true to indicated the joined thread has exited, false otherwise.


<-- Example 1 ------------------------------->



// The semantics here are:

//     The current thread calling Join(), "joins" the myThread thread instance.

//     myThread is the thread being joined to.

//     The current thread is then blocked until the myThread's ThreadStart delegate target 

//     has returned control back to the CLR by exiting.



myThread.Join();  // blocks until myThread completes



// At this point, myThread has exited.



<-- Example 2 ------------------------------->



// Created on some managing thread

ManualResetEvent quit = new ManualResetEvent(false);

// ThreadProc is defined and used as the delegate target.

// Somehow, the ThreadProc has access to quit WaitHandle

Thread t = new Thread(new ThreadStart(ThreadProc));



// managing thread signals created thread it is time to quit

quit.Set();



// Assumes the created thread will monitor the quit WaitHandle to know when to quit.

// The amount of time until the thread quits is application dependent.

// Choose an appropriate timeout for the Join below when considering this.



// later the managing thread waits for the created thread to exit

if (!t.Join(2000)) {

    // report aborting thread

    t.Abort();

}

What happens when an object is created that implements an interface?

2004-06-05T12:45:00.000-07:00

Start with C# definition of an interface. From the C# specification: "An interface defines a contract. A class or struct that implements an interface must adhere to its contract."

An interface type declaration simply declares a new type that can be implemented by a class or struct. A classs or structure can implement an interface by inheriting from it then provide the interface member implementations. Another interface can also inherit from an interface type too. This simply requires the class or struct inheriting the interface inheritance family to implement the combined interface members from the entire interface inheritance family. A class or struct can also explicitly derive from multiple interfaces. C# supports the notion of "single" inheritance. This means "single" implementation inheritance. But, a class or struct can derive from multiple interfaces. This is because interfaces do not provide any implementation.

At runtime, a interface reference can be refer to. You can declare a reference to an interface, but you cannot explicit instantiate an interface. This is because, an interface type, by itself, does not provide any implementation. To refer to an interface, you must instantiate the class or struct that implemented the interface. Once this is created, you can assign this implementing type to a reference of the interface type it implemented. That is allowed because of the implicit type conversion rules. These rules partially state that a derived type may be implicitly converted to another inherited type. So, any class or struct inheriting from an interface and instantiated at runtime can be implicitly converted to the interface type it inherited from. But, nothing really changes with this instantiated type when it is assigned to one its inherited interface types. The real runtime type is still the same type that implemented the interface.

At runtime using the interface reference simply restricts the members you can call on the runtime type's instance that implemented the interface. The restriction allows only the interface's members and any of its inherited interface methods. You can verify this with the following code:


interface IFooBase {

    void FooBase();

}

	

interface IFoo : IFooBase {

	void Bar();

}

	

public class FooImpl : IFoo {

	public void FooBase() {

	 	Console.WriteLine("FooImpl.FooBase called.");

	 }

	public void Bar() {

	 	Console.WriteLine("FooImpl.Bar called.");

	 }

	public void Bar2() {

	 	Console.WriteLine("FooImpl.Bar2 called.");

	 }

}



// Then in some client code:

IFoo fii = new FooImpl();

fii.FooBase();

fii.Bar();

fii.Bar2(); // Compile error: "IFoo does not contain a definition for Bar2



Console.WriteLine("fii's runtime type is: {0}", fii.GetType());



// ...



// After deleting the code for the compile error above, compiling and running

// the console output is:

FooImpl.FooBase called.

FooImpl.Bar called.

fii's runtime type is: FooImpl

Protecting against InvalidOperationException when dequeueing from an empty queue

2004-06-03T23:09:00.000-07:00

MSDN documents that Queue.Dequeue()ing from an empty System.Collections.Queue will throw an exception of type InvalidOperationException. They also suggest as one alternative to wrap the call in a try/catch and be done! But a simple check to Queue.Count before Queue.Dequeue()ing will eliminate the performance penalty incurred for the thrown exception. It is also a proactive coding measure that doesn't add too much complex and removes the need for the call specific catch handler. But, if we do not implement this correctly, the exception can still be thrown.

Why?

Because of the race condition that exists between the separate calls Count and Dequeue. Only a new Queue created using Queue.Synchronized is synchronized. Queue.Synchronized returns a synchronized wrapper for a new'd Queue passed to it. But, Queue can only synchronize access to itself during the life of a single call. To fix and remove the race condition, we need to lock access for our external code to call Queue.Count then Queue.Dequeue before releasing the lock. Synchronizing a Queue (which implements ICollection) should always synchronize the return from Queue.SyncRoot and not the Queue instance. This is to support derivations of a synchronized Queue which can also synchronize on it too.

To simply client access we can provide a simple wrapper class that implements the correct code for locking the Queue for both calls as follows:


public class Shared {

	private Queue q;

	private ManualResetEvent workToDo;



	public Shared(ManualResetEvent evt) {

		workToDo = evt;

		q = Queue.Synchronized(new Queue());

	}



	public void Enqueue(object o) {

		q.Enqueue(o);

		workToDo.Set();

	}



	public object Dequeue() {

		object o = null;



		// lock q access

		lock(q.SyncRoot) {

			int c = q.Count;

			// check to see if empty

			if (c > 0) {

				o = q.Dequeue();

				if (c == 1) {

					// only had one item and Dequeue just removed it, so signal

					workToDo.Reset();

				}

			}

		}



		return o;

	}

}

Writing an infinite loop?

2004-05-30T10:20:00.000-07:00

Application code solutions sometimes have use for infinite loops. Consider the following:


    for(;;);



    // or



    while(true);

But this code is dangerous because once executed the running thread can never get past this code (unless another thread forces a Thread.Abort on this thread). Instead this code should be written as follows:


    // psuedo code

    while(true) {

        if ( some quit condition is true) break;

        // do a piece of the work here

    }

But, where would code like this be used?

This kind of code occurs quite a bit in worker threads waiting for some work to do. It is a common code pattern. All code in the looping statements body is critical. The "quit condition" must be checked frequently. This implies that the work to do must be short. Usually this is one smaller chuck of work out of the larger set of work it was given to accomplish.

What causes the quit condition to become true?

That is always application specific, but usually some other thread in the application eventually sets this quit condition to true.

What if there is no work? Won't the thread spin and waste CPU cycles?

Yes. If no work is available to do and the quit condition is not true, this loop should sleep. In C#, Thread.Sleep can be used with a timeout of at least 1ms.

Thread safe access to a System.Windows.Forms.Control

2004-05-28T08:39:00.000-07:00

From the MSDN documentation (re. April 2004 edition), the only methods that can be safely called from any thread are: Control.BeginInvoke/EndInvoke/Invoke/InvokeRequired/CreateGraphics.

Control.Invoke is a synchronous call that can be safely called to update a Control. The call can be made from any thread and is passed a delegate (of any type). An overload of this method takes an object[] as the parameters your delegate requireds. The return from the Invoke is the return from your delegate - if any. These two forms of Invoke are:


public object Invoke(delegate method);

public virtual object Invoke(delegate method, object[] args);

The following is a code sample of using a type that can call Control.Invoke from any thread.


// Using the second overload of Invoke from above

class MyClass {

    private delegate void UpdateListbox(string msg);

    private ListBox lb;



    // This ctor can be called on any thread and passed the reference to the Listbox

    MyClass(ListBox lb) {

        this.lb = lb;

    }



    // Any thread can call this method which indirectly updates the Listbox using Control.Invoke.

    // The call is synchronous, so the calling thread is blocked until the Listbox is update.

    // Consider Control.BeginInvoke for the asynchronous (non-blocking) solution.

    void UpdateLB(string newMsg) {

        UpdateListbox ulb = new UpdateListbox(this.OnUpdate);

        lb.Invoke(ulb, new object[] { newMsg });

    }



    // Do not directly call this method.

    // This method is designed to use only as a delegate target that is invoke on the thread that 

    // created the Listbox.

    private void OnUpdate(string msg) {

        lb.Items.Add(msg);

    }

}

Creating a synchronized Queue

2004-05-28T08:37:00.000-07:00

using System.Collections;

// myQueue is now protected, but only during the a method call
Queue myQueue = Queue.Synchronized(new Queue());

C# Development

Using Thread.Join to Ensure a Worker Thread Has Exited

What happens when an object is created that implements an interface?

Protecting against InvalidOperationException when dequeueing from an empty queue

Writing an infinite loop?

for(;;); // or while(true);

// psuedo code while(true) { if ( some quit condition is true) break; // do a piece of the work here }

Thread safe access to a System.Windows.Forms.Control

public object Invoke(delegate method); public virtual object Invoke(delegate method, object[] args);

Creating a synchronized Queue

for(;;);

// or

while(true);

// psuedo code
while(true) {
if ( some quit condition is true) break;
// do a piece of the work here
}

public object Invoke(delegate method);
public virtual object Invoke(delegate method, object[] args);