Thread m_thread = new Thread();
	m_thread.start();

There are two basics way to implement a some code as thread, subclass Thread or implement the interface Runnable. In general though, you don't want to override any of the methods of the Thread class, so you simply implement Runnable. Once you have a class that implements Runnable, we wrap a Thread around it, and start it:

	Thread m_thread = new Thread(new RunnableObject());
	m_thread.start();

Runnable

The interface java.lang.Runnable is simple: public interface Runnable { public void run(); } So to make a thread, we make a class that implements Runnable, that does what you want it to do inside the run() method. Then when the Thread we wrap around it starts, the JVM will spawn a new thread, and have that thread call the run() method. The thread will continue executing until the run() method returns.

Synchronization

This seems simple enough, but as you've seen, the hard part is keeping threads from stepping on each other. Dining Philosopher's Problem Java provides monitors to allow you to maintain critical sections. Say you a LinkedList list, that you want to make sure that only one thread modifies at a time. To do this, we wrap all the sections of code that modify this linked list in synchronized blocks: synchronized(list) { //Modify here } If a thread is inside this block, and another thread wants to enter it, Java will force the second thread to wait for the first one to finish before it continues. A synchronized method, turns out to just be functionally the same as: //synchronized void foo() // { //body } void foo() { synchronized(this) { //body } } You can choice how fine-grained to have your locking. That is, do we lock an entire object when we want to do something with it, or just the fields we are concerned with. The smaller the parts of the code which are being locked, the more fine-grained the locking is. The more fine-grained the locking, the more threads can concurrently execute. Notice, however, that this is merely a performace concern. For beginners to multithreaded programming, it's better to make the locking simple and clear, then to make it fine-grained.

Start, Stop, Pause

In many situations, we want to be able to stop a thread, or to pause it. Then to later start it again. If you look at the Thread API, you'll see that there used to be handy methods for do this, but they have been deprecated, as they were dangerous. The proper way of handling this situation is to have flags that your thread checking occassionally, which tell it to stop its execution (throw an exception that is caught in its run() method which has that method return), or to pause its execution. To pause a thread, we just have the thread call the wait() method on itself. This will cause the thread to pause until it has been notify()'ed (also known as waking the thread up). Note that your thread should always check its flags after being awoken, do some complicated implementation issues, you should never assume that you've been woken up when you are supposed to. You may ask, how do a stop a thread NOW. Well, Thread does allow you to tell a thread .destory(), but this isn't something you really want to do, in most cases. Same with the idea of pausing a thread. The problem is that you don't want to kill/pause a thread while it is in the middle of a critical section. Firstly, because it may be doing something which if it doesn't finish will leave its data structure in an undetermined state, and secondly because the methods provided by Java for controlling threads, don't cause the thread to give up its monitors. So if you kill a thread in the middle of a critical section, no one else will able to enter that section.

Putting Things Together
	Demostration of a reasonably complex multithreaded swing application: ThreadControlDemo Source Code Class Discussion of Design

Exercise
	This week's exercise will be announced in class. For Monday, Due Wednesday 5PM For Wednesday, Due Friday 5PM