Why should most logic be in the monitor objects and not in the thread objects when writing concurrent software in Java?

Question

When I took the Realtime and Concurrent programming course our lecturer told us that when writing concurrent programs in Java and using monitors, most of the logic should be in the monitor and as little as possible in the threads that access it. I never really understood why and I really would like to.

Let me clarify.

In this particular case we had several classes.

Lift extends Thread
Person extends Thread
LiftView
Monitor, all methods synchronized.

This is nothing we came up with, our task was to implement a lift simulation with persons waiting on different floors, and theses were the class skeletons that were given.

Then our lecturer said to implement most of the logic in the monitor (he was talking about class Monitor as THE monitor) and as little as possible in the threads.

Why would he make a statement like that?

Answer 1

He's getting you to do some really elementary multithreading. Or perhaps you could call it single-threading. If everything's in the Monitor class, and every method there is synchronized, nothing can get accessed by more than one thread at a time. This gives up most of the benefits of multithreaded code and is not apt to teach you much. On the other hand, the program is apt to work, thus building confidence in the students. It's no doubt a good starting point.

Hard core multithreading means lots of threads accessing the same fields at the same time. It keeps all the cores on your computer busy and so gets the work done faster. But it's insanely tricky, generating lots of unsolvable bugs. I think your lecturer is trying to ease you into it slowly. (And probably trying to save himself some work helping students whose programs have extremely subtle bugs. And also let the students finish all their assignments by the end of the semester.)

Answer 2

I'm not sure what to say about your lecturer.

There's almost never any reason to extend Thread. The usual practice in java is to implement Runnable. This Runnable is then passed to a thread or a pool of threads, who perform the work specified in run(). Think of the body of the run() method as a unit of work to be performed by a thread.

Putting the logic in a singleton object with synchronized methods.... this makes no sense at all and is a very bad design. Calling a synchronized method locks on the surrounding object, which means every thread calling synchronized methods on that object blocks all the other threads, even if they're calling different synchronized methods. If your entire simulation is being run through a singleton "Monitor" class, all threads will have to block all other threads every time they call one of the methods. This is horrible for performance and it's a great way to create deadlocks if you have more than one class like this in your program. This whole approach is a giant can of worms.

A properly designed multi-threaded program will generally have a bunch of Runnables that represent units of work. Some class will generate these Runnables and feed them to a pool of threads who will perform them. If these Runnables aren't sharing resources, there's no need for grabbing locks. If Runnables are sharing resources, you figure out a way to represent those resources with a lock object and give out those lock objects to the Runnables so that they can synchronize on them during the run() method.

The goal is to have the threads block one another to the minimum extent possible. This is the exact opposite of the model your instructor provided.