Multithreading with C#
Pages: 1, 2, 3, 4

Using Threads

There are a bunch of standard operations that a Java programmer wants to be able to perform on Threads: test if the thread is alive, join a thread until it dies, kill a thread, etc.

Table 1: Thread management functions A mapping between Java's java.lang.Thread methods and their equivalent in C#'s System.Threading.Thread object
Java	C#	Notes
setDaemon( boolean on) method	IsBackground set property	Makes a given thread a daemon thread (the program will terminate when all that is left are daemon threads).
isDaemon() method	IsBackground get property	Returns true if the thread is a background thread.
isAlive() method	IsAlive get property	Returns true if the thread is alive.
interrupt() method	Interrupt() method	While in Java this sets the "interrupted status" of the thread and can be checked to see whether a thread has been interrupted, there is no such equivalent check in C#. However, in C#, calling Interrupt on a thread that is not blocking will cause the next blocking call to automatically unblock.
isInterrupted() method	n/a	Returns true if this thread has been interrupted.
sleep( long millis ) and sleep( long millis, int nanos )	Sleep( int millisecondTimeout ) and Sleep( System.TimeSpan ) methods	A static call that pauses the thread of execution for a given amount of time or until the thread is interrupted -- this method will throw a java.lang.InterruptedException in Java and a System.Threading. ThreadInterruptedException in C# (remember that all C# exceptions are run-time).
join(), and join( long millis ), and join( long millis, int nanos ) methods	Join(), Join( int millisecondTimeout ), and Join( System.TimeSpan ) methods	Unlike the Java join methods which are simply timeouts, the C# versions return a boolean upon termination to signify whether the thread died (true) or the timeout expired (false).
suspend() method	Suspend() method	Functionally the same -- the C# methods exhibit the same properties that caused the suspend() method in java.lang.Thread to be deprecated. This method is deadlock-prone: if a thread holding a lock on a system-critical resource is suspended, then no other threads can access the resource until the former thread is resumed.
resume() method	Resume() method	Resumes a suspended thread.
stop() method	Abort() method	See "Stopping Threads" following this table.

Stopping Threads

The Thread.stop method in Java has been deprecated, as it can silently put the running program into an inconsistent state; upon a stop() method call, an unchecked java.lang.ThreadDeath error will propagate up the running thread's stack, unlocking any locked monitors as it goes along. As these locks are being indiscriminately released, the data they they are protecting may be left in an inconsistent state.

According to the current Java documentation, the recommended manner to stop a thread is to have the running thread check a variable which another thread could flip to signal a "time to die" condition such as in the following example

 // the condition variable
 private boolean timeToDie = false;   

 // a runnable that checks the condition variable
 // on every iteration
 class StoppableRunnable
 extends Runnable {
   public void run() {
     while( !timeToDie ) {
       // do stuff

     }

   }

 }

The above statements hold true for C#'s Abort method also -- upon calling Abort, an uncatchable System.Threading.ThreadAbortException will propagate up the stack, silently killing the thread. It too will free any monitor locks that the thread currently holds and may place the protected data structures into a bad state. I recommend using a pattern similar to the one laid out above to notify a thread that it is time to die.

In both languages, it is worth noting, calling either stop() or Abort() will cause the finally clauses of any try-catch-finally block it is currently in to execute.

Pages: 1, 2, 3, 4

Next Page