1

I was working on a Java EE app that took in user requests from a UI and then keyed off a lon workflow asynchronously for each of these requests using ExecutorService (SinglethreadExecutor). Now since i was using a SinglethreadExecutor and because there was genuine need for the requests to be served one at a time, i did not feel the need for thread safety. Is my understanding correct ?

Recently i had asked a question Issue when executing asynchronous tasks using ExecutorService and the solution to this question was that i make my code thread safe. I'm looking if any shared resources that I'm using in my code is causing the need for this thread safety but would just like to be sure that my understanding of the scenario is correct.

FYI, I have implemented my ExecutorService in a servlet as mentioned in Running a background Java program in Tomcat

Community
  • 1
  • 1
ping
  • 1,229
  • 3
  • 21
  • 41
  • (case is closed, can't post as answer) After reading and testing I can say that any mutable objects accessed/modified **ONLY** in a `SingleThreadExecutor` are thread safe. Mutable objects accessed/modified in `multiThreadExecutors` and `new Thread(runnable)` are not. If you intend to pass the mutable object to another thread afterwards consider using atomic or immutable copy. Alternatively you could pass it using a runnable/callable but that would only guarantee that the mutable object does not have a value **older** than the moment of being passed. – Then Enok Jul 22 '20 at 21:48
  • Ps: this question is regarding the thread safety (surrounding with a `synchronized` block) of a mutable object accessed inside a `SingleThreadExecutor` (we all know we need to synchronize mutable objects in `mutiThreadExecutors`) whereas the suggested duplicate is regarding the thread safety of accessing the `ExecutorService` object from another thread – Then Enok Jul 22 '20 at 21:54

2 Answers2

3

Your requests will be passed to a different thread to be executed. Even if this thread doesn't access shared data structures, the passing of the request to the thread and the returning of the result need to be properly synchronized.

If you use one of the submit or invoke methods which use a Future object for returning the results, you can assume that the appropriate synchronization is performed. The javadoc for ExecutorService says this:

Memory consistency effects: Actions in a thread prior to the submission of a Runnable or Callable task to an ExecutorService happen-before any actions taken by that task, which in turn happen-before the result is retrieved via Future.get().

In short, if the requests / tasks don't use shared data structures and you use the interface methods provided, then you should be OK.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
1

There are two things that you need to consider when you need to make something "thread safe": When does a thread make data visible to anyone else? When does a thread try to read shared data?

Imagine this situation: Thread A gets the request. It works a bit on it. Then it calls a method foo() that gets the request as a parameter. foo() starts a new thread. The thread puts the reference to the request as a private, non-final field.

In hardware, thread A has copied the request into the L1 cache of the CPU core on which it runs. Since there is no synchronization between the two threads, A has no idea that some other thread might want to read the modified request, so it never flushes the cache (or it does it too late).

This means that thread B will get a stale request object. It won't see any changes made by thread A. As you can imagine, this usually works: If A doesn't change the request, B works. It breaks as soon as you change the code of A and you have a "but it worked yesterday!" situation.

To fix this, you must tell A to flush its caches even if the current version of your code works without it. There are several ways to do it; Stephen C described one. Two other ways:

  • You can synchronize foo() - A thread must flush when it enters a synchronized block.
  • Make the request a final field of B - Object graphs referenced via final fields must be completely flushed at the time the type construction has completed (where type == the class which contains the final field).
Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • 1
    *"Object graphs referenced via final fields must be completely flushed at the time the field is assigned."* - Not strictly correct. They must be flushed by the time type construction has completed; see JLS 17.5.1 (first 2 sentences). This is one reason why a constructor shouldn't publish `this`. – Stephen C Jan 04 '12 at 00:42