Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Will synchronizing really have an impact in this case?  (Read 1252 times)
0 Members and 1 Guest are viewing this topic.
Offline theagentd
« Posted 2011-12-30 11:55:15 »

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.

Myomyomyo.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #1 - Posted 2011-12-30 13:55:04 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2011-12-30 15:57:54 »

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 Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2011-12-30 16:54:41 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline sproingie

JGO Kernel


Medals: 202



« Reply #4 - Posted 2011-12-31 02:52:56 »

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.


Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #5 - Posted 2011-12-31 02:54:55 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #6 - Posted 2011-12-31 10:09:02 »

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.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline theagentd
« Reply #7 - Posted 2011-12-31 10:39:23 »

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!

Myomyomyo.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (43 views)
2014-10-17 03:59:02

Norakomi (33 views)
2014-10-16 15:22:06

Norakomi (26 views)
2014-10-16 15:20:20

lcass (30 views)
2014-10-15 16:18:58

TehJavaDev (60 views)
2014-10-14 00:39:48

TehJavaDev (60 views)
2014-10-14 00:35:47

TehJavaDev (50 views)
2014-10-14 00:32:37

BurntPizza (66 views)
2014-10-11 23:24:42

BurntPizza (38 views)
2014-10-11 23:10:45

BurntPizza (80 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!