Will synchronizing really have an impact in this case?

[theagentd]

I want to modify a large number of ArrayLists from multiple threads. Not very many of the ArrayLists are modified per thread so the chance of two threads modifying the same list is very small.

Consider this example:

Thread 1:

1   2   3

synchronized(listA){     //Modify listA }

Thread 2:

1   2   3

synchronized(listB){     //Modify listB }

Would the synchronization have any performance impact what so ever in this case? I believe it shouldn't.

[Riven]

Synchronization is the heaviest operation in Java. It can take thousands of CPU cycles to lock on an object and pretty much disables aggresive out-of-order execution of instructions, as the JVM has to guarantee X happened before Y.

There are however optimisations in the HotSpot JVM that can replace a 'monitor enter' with a busy-loop, or even verifying that locks are never accessed concurrently, in which case the sync can be optimized away. Once the JVM determines that a lock is contented, it will rollback these optimisations.

Having said all that, the performance overhead can be negligible, depending on how much work you actually perform within the synchronized block. So as always, it depends. Benchmark it in a realworld scenario and draw conclusions from that.

[princec]

Very hard to benchmark in a real-world scenario unless you've got a whole pile of real-world hardware configurations and operating systems to play with.

Cas

Games published by our own members! Check 'em out!

[Riven]

I think it's simply key to get a lot done in your sync-block, so that no matter how big the overhead, it becomes negligible.

[sproingie]

Doing lots of work inside the synchronized block is the best way to make sure your locks become bottlenecks or cause outright deadlock.  The fastest solution is not sharing the lists between threads in the first place.  Hard to say if that's possible from the description.

[Riven]

Doing lots of work inside the synchronized block is the best way to make sure your locks become bottlenecks or cause outright deadlock.  The fastest solution is not sharing the lists between threads in the first place.  Hard to say if that's possible from the description.

and then there is this thing called context:

Not very many of the ArrayLists are modified per thread so the chance of two threads modifying the same list is very small.

[delt0r]

I would recommend using locks from java.util.concurrent. In all my tests they are never slower than synchronized and sometimes are faster because you have more control. The biggest gains can come from cases where there are many reads and less often writes... and its readWriteLock for the win. I have seen great performance using that on some fluid simulation stuff where many threads work on common data structures.

[theagentd]

In my case, I have two solutions to my problem. One is to allow the threads to modify the lists, and one is to defer the changes by saving them and execute them single-threaded after everything. I think it will be faster to use synchronization since I will not be doing many changes per update, like 80% of the time it will be 0 changes but sometimes several in a single frame. The chance of two lists being modified in the same frame is extremely low, but if synchronization is as expensive as you say...

Concerning how much work I actually do in each change, I realized that I might have to keep the lists sorted, since the order of the objects in them may have an effect if the scripts used in the game are order-dependent (I need determinism for network synchronization and replaying). I might therefore have to switch from ArrayList to some kind of sorted list or set, which would of course take more time to change...

In the end, I guess only an actual benchmark would be able to give me an answer. Thanks for all the quick responses!