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
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?

  • 4
    This makes no sense at all. When you extend something, you create an "is a" relationship, as in dog extends animal. A Person is most decidedly not a Thread. Implementing most of the logic in the monitor makes no sense either. I don't think your lecturer knew what he was talking about. Nov 8, 2012 at 22:33
  • cross-posted from SO: stackoverflow.com/questions/13295745/…
    – gnat
    Nov 9, 2012 at 7:16

2 Answers 2


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.)

  • "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 is what confuses me. As I see it as much as possible should be done in the threads and the monitors should only be used for data sharing using very short methods. If everything is executing in the monitor, why multi thread? Except for the cases where the treads are blocked by something or other.
    – evading
    Nov 8, 2012 at 22:53
  • @refuser: You are quite right. I hope the idea here is to get you a single threaded program that works. From there, in incremental steps, you can work towards a seriously multithreaded program. That way you only have to figure out one or two impossible bugs at a time. The key point here is that when you run two or more threads at the same time, very strange things will start to happen, and I hope the lecturer's concern with this Monitor class is to limit the chaos--and not scare off the lecturees. Nov 9, 2012 at 14:15

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.

  • Java 5 (over a decade old) introduced Callable<T>, Executor, Future<T>, and related classes. While you are correct that extending Thread is generally a bad idea, you are still describing an obsolete threading model in Java.
    – user22815
    Oct 6, 2016 at 16:12
  • Yeah I'm aware of that. I described feeding runnables to a pool of threads- because I had the Java.util.concurrent model in mind. See my second from last paragraph.
    – Jim W
    Oct 6, 2016 at 16:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.