Synchronization on the local variables

Question

I have a multithreaded Java code in which:

• several threads read stateful objects from the synchronized shared storage (i.e. as a result of this, some threads may reference the same objects);
• each thread then invokes a method process() and passes its object there;
• process() processes objects in some way, which may result changing the objects state;
• these state changes should be synchronized.

I've created a method like that:

public void process(Foo[] foos) {     for (final Foo foo : foos) {         if (foo.needsProcessing()) {             synchronized (foo) {                 foo.process();  // foo's state may be changed here             }         }     } } 

To the best of my knowledge, this looks legit. However, IntelliJ's inspection complains about synchronizing on the local variable because "different threads are very likely to have different local instances" (this is not valid for me, as I'm not initializing foos in the method).

Essentially what I want to achieve here is the same as having method Foo.process() synchronized (which is not an option for me, as Foo is a part of 3rd party library).

I got used to the code without yellow marks, so any advice from the community is appreciated. Is this really that bad to do synchronization on locals? Is there an alternative which will work in my situation?

Thanks in advance!

Answer 1

if (foo.needsProcessing()) {     synchronized (foo) {         foo.process();  // foo's state may be changed here     } } 

I think there is a race condition in the above fragment that could result in foo.process() occasionally being called twice on the same object. It should be:

synchronized (foo) {     if (foo.needsProcessing()) {         foo.process();  // foo's state may be changed here     } } 

---

Is this really that bad to synchronize on locals?

It is not bad to synchronize on locals per se. The real issues are:

• whether the different threads are synchronizing on the correct objects to achieve proper synchronization, and

• whether something else could cause problems by synchronizing on those objects.

Answer 2

Stephen C's answer has problems, he's entering a lot of synchronization locks pointlessly, oddly enough the better way to format it is:

    public void process(Foo[] foos) {         for (final Foo foo : foos) {             if (foo.needsProcessing()) {                 synchronized (foo) {                     if (foo.needsProcessing()) {                         foo.process();  // foo's state may be changed here                     }                 }             }         }     } 

Getting the synchronization lock can sometimes take a while and if it was held something was changing something. It could be something changed the needing-processing status of foo in that time.

You don't want to wait for the lock if you don't need to process the object. And after you get the lock, it might not still need processing. So even though it looks kind of silly and novice programmers might be inclined to remove one of the checks it's actually the sound way to do this so long as foo.needsProcessing() is a negligable function.

---

Bringing this back to the main question, when it is the case that you want to synchronize based on the local values in an array it's because time is critical. And in those cases the last thing you want to do is lock every single item in the array or process the data twice. You would only be synchronizing local objects if you have a couple threads doing a bunch of work and should very rarely need to touch the same data but very well might.

Doing this will only ever hit the lock if and only if, processing that foo that needs processing would cause concurrency errors. You basically will want double gated syntax in those cases when you want to synchronize based on just the precise objects in the array as such. This prevents double processing the foos and locking any foo that does not need processing.

You are left with the very rare case of blocking the thread or even entering a lock only and exactly when it matters, and your thread is only blocked for at exactly the point where not blocking would lead to concurrency errors.