Thread Patterns

Here is a list of my Thread Patterns

One Ring Pattern
Zebra Pattern
Star Trek Anti-Pattern
Medusa Pattern
Yoda Pattern

See also my Queue Patterns.

Yoda Pattern

In the previous part, I talked about the Medusa Pattern, where I limited the number of threads. Now I want to go even further: I want to remove all threads.

In fact, there is a particular case where threads are more of a nuisance. I am thinking about the small creature that likes the green color: the unit tests. As Yoda would say: “too much faith in threads you have”. When faced with multithreading in a unit test, you often have to revert to inserting sleep() commands, or performing some more complex tricks using wait() and notify() or equivalent.
But in reality, what you would really like to do is to get rid of the threads just for the testing. If you are using an Executor, it is not complicated to replace it with another one that executes the task in the current thread:

Executor forTest = new Executor() {

   public void execute(Runnable command) {

       command.run();

   }

};

Since we are using Java 8 (at least) and Executor is a functional interface, we can revert to use a lambda:

Executor forTest = command -> command.run;

And even better to use method reference:

Executor forTest = Runnable::run;

Medusa Pattern

Last time, we saw the Star Trek Anti-Pattern, where the number of threads would go out of hands, to infinity and beyond.The easy solution to that is to limit the number of threads.

That is what I call the Medusa Pattern, from the name of that famous Gorgona that would freeze people by just looking at them. We are going to freeze the number of threads in a thread pool:

Executors.newFixedThreadPool(n);

Now comes the big question: what should be ‘n’? How many threads should I have in my pool? The usual accepted answer is: as many threads as the number of cores, plus one because one thread is often in waiting. In his book “Concurrency in Practice”, Brian Goetz answers this question with this formula:

t = c * (1 + w / s)

Where t is the number of threads, c is the number of cores in your machine, w is the waiting time, that is the average time your threads spend waiting, and s is the service time, that is the time your threads spend in average doing some useful work. You can see that if your threads are very busy, with almost zero waiting time, there should be as many threads as the number of cores, and we come close to the usual accepted rule of thumb.


On the other hand, if your threads spend a lot of time waiting, the value of t can be quite high. For instance, I work in a project where we have a monitoring application that monitors over 300 servers. Since monitoring threads spend their time waiting for a ping, we decided to have as many threads as servers.


We’ve seen cases with one thread, an infinity of threads, a fixed number of threads, but there is a special case where you do not want any thread. We’ll cover this in the Yoda Pattern. See you next time.