Thread safe services

Last month I explained how to tune Acceleo standalone engine threading. But services were still running in mutual exclusion because historically services didn't need to be thread safe. The result was a performance loss.
Services of a given service class couldn't run in parallel by default. It means threads will have to wait for other threads to run services. I noticed that a lot of service classes are thread safe, they don't use field or static references.

But as I can't decide if a service class is thread safe or not for you, I added an interface that bypass the mutual exclusion zone for a given service class. It allows multi threads to run services of a service class. This interface is IThreadSafeService. It declares nothing, so you just have to add the implements clause as following:

public MyServices implements IThreadSafeService {
...
}

But be aware, if you use this interface and your service class is not thread safe it can lead to random boggus behavior. And it can be difficult to find out what is the root cause of your troubles.

Acceleo standalone and multi-threading

One of the main features of the standalone Acceleo engine is to provide multi-thread support. This allows us to divide the code generation time according to the count of available processors, effectively cutting the generation in half on some machines. To share the work between threads, the input model is divided into groups of objects; each group is then queued till a thread can process it.

There are two parameters to tweak the multi-threaded generation. The first one is the number of threads to run simultaneously, the default value being the number of available processors plus one. This allows us to use all available processors, the one supplementary thread used to cover synchronization waiting time. While some threads are waiting for another one, one processor is free to run the thread which was waiting for an idle processor.

The second parameter is the number of objects per group, the default being 20 objects per group. This parameter is very important since its allows you to find the optimum between load sharing and thread management overhead. Your objects groups will not be processed using the same amount of time. So Imaging you divided your model into two groups by setting number of objects in the model divided by 2. The group which runs faster will have to wait for the slower group at the end of the generation. In this case you are losing time. On the oposite you can put a single object per group. This way you minimize the loss of time at the genretation end. But threads will spend more time peeking groups in the queue since there are much more groups.

To set thoses parameters have a look at :
- Extension.setThreadsNumber(int)
- Extension.setEObjectsPerThread(int)