Search code examples
javamultithreadingconcurrencyvaadin

Synchronized with ThreadLocal vs InheritableThreadLocal?


I am implementing a vaadin application following this thread local pattern.

The state of the application is modified by several worker threads. Hence, to notify the application that its state changed, I add a progress indicator.

Reading the progress indicator sample, I see this :

        // All modifications to Vaadin components should be synchronized
        // over application instance. For normal requests this is done
        // by the servlet. Here we are changing the application state
        // via a separate thread.
        synchronized (getApplication()) {
            prosessed();
        }

So basically, I think I just have to modify the call to getApplication to get the instance of my application (just call getCurrent):

  private static ThreadLocal<MyApplication> currentApplication = new ThreadLocal<MyApplication>();

    @Override
    public void init() {
        setCurrent(this); // So that we immediately have access to the current application

        // initialize mainWindow and other stuff

        // Register a transaction listener that updates our ThreadLocal with each request
        if (getContext() != null) {
            getContext().addTransactionListener(this);
        }   
    }

    /**
     * @return the current application instance
     */
    public static MyApplication getCurrent() {
        return currentApplication.get();
    }

The problem is that my worker thread dies of starvation because It cannot acquire the mutex on the application. One solution provided by the vaadin forum is to use InheritableThreadLocal. It works but I don't get it why.

From the javadoc :

This class extends ThreadLocal to provide inheritance of values from parent thread to child thread: when a child thread is created, the child receives initial values for all inheritable thread-local variables for which the parent has values. Normally the child's values will be identical to the parent's; however, the child's value can be made an arbitrary function of the parent's by overriding the childValue method in this class.

Inheritable thread-local variables are used in preference to ordinary thread-local variables when the per-thread-attribute being maintained in the variable (e.g., User ID, Transaction ID) must be automatically transmitted to any child threads that are created.

My worker thread cannot get the lock because it does not receive initial values ? Am I misinterpreting something ? Except this problem, what are the potential pitfalls of using InheritableThreadLocal I should be aware of ?

Thanks.


Solution

  • The key for understanding how it works is method in ThreadLocal class:

    static ThreadLocalMap createInheritedMap(ThreadLocalMap parentMap) {
       return new ThreadLocalMap(parentMap);
    }
    

    It is designed to be called only from Thread constructor. The method

    protected Object childValue(Object parentValue)
    

    of InheritableThreadLocal class is used to set the initial value of the InheritableThreadLocal variable in the child thread as a function of a ThreadLocal variable (passed as a parameter) in the parent thread. This method is called from within the parent thread before the child thread is created and the default implementation will make the child values identical to parent's, but we can override the childValue() method to set the child value as a function of the parent value for those ThreadLocals which have values in the parent thread. By default the childValue() returns the same input argument, but again an override of the childValue() method might change this behavior as well.

    So InheritableThreadLocal works almost like ThreadLocal and it has the same synchronization pitfalls.