I was wondering if anyone could give me some advice on this, without directing me to a API, rather tips on when to use it, and when not to use it?
synchronized(this) {
}
Hope someone can help, thanks.
I say never use synchronization unless you really really need to. Multi-threading is a pain in the ass and synchronization makes things much more complicated, not to mention the huge performance hit.
Thanks, guess i’ll look up on it some more, remove it from my game.
I don’t even get why you would want to synchronize your game. ???
Maybe you want 2 000 000 particles instead of 800 000? Maybe you want 1000 units instead of 300? Or maybe you just want to block and wait for something to happen without pausing your whole game.
Oh. ;D
You may want to see this question.
lol, that’s the post I was looking at right after I replied to ra4king. :o
Thanks guys.
Okay, that came out kind of arrogant and irritated sounding… It’s useful when you need to synchronize threads in some way. For example you can’t modify a list from two threads at the same time. You can’t even read and write to the same list from two threads at the same time. Therefore you use synchronize() blocks to acquire a lock on an object. While a thread is inside a synchronized() block, no other thread may acquire the same lock and will block (wait) until the first thread releases the lock (= exits the synchronized() block). In the above list example, you can acquire a lock on the list to ensure that it is only accessed by one thread at a time.
Multithreading is often done for performance reasons, so you want to avoid synchronizing as much as possible. Not only does too much synchronization defeat the purpose of multithreading since only one thread can work at a time, there’s also a massive overhead for synchronization, so you have to know what you’re doing to even get a performance increase. The potential is pretty good though. Theoretically you can get a 4x speedup on a quad core, even more with hyperthreading or more cores.
The second usage case is when you want to wait for something to happen. Maybe you’re waiting for data from a network connection. If no data is received your program will be locked indefinitely, so you need to put the blocking code into a different thread so the game loop can still run independently from the network code. However, you still need to somehow pass data from the network thread to the main thread in a thread-safe way. A normal approach is to put the received data in a queue which is checked by the game loop. This queue needs to be synchronized or you’ll get undefined extremely random behavior. This of course has nothing to do with gaining performance.
Geeze, thanks theagentd.
I removed about 5 synchronized statements from the game (just posted it in WIP), seems my fps went up ;D
(guess i had no idea about sync statements, will reserve for threads only >.<)
Wouldn’t syncronhized threads block/speed up your game depending on the usage?
Threads only work in parallel on multiple cores if they AREN’T synchronized, so you want to use as little synchronization as possible.
That’s what I thought it was doing at first :emo:
The only reason to not use synchronized (this) and not synchronize on some other monitor object instead is if your object might need more than one such monitor, and in that case, you probably need to split up your class design anyway to use more composition and put the synchronized methods on the relevant components instead.
You should hardly ever need to use a synchronized block; break it up into a synchronized method instead. The method call overhead is dwarfed by the synchronization overhead anyway.
Also, don’t think you can just replace a synchronized block/method with some sort of Lock or other mutex mechanism: synchronization also makes sure that updates are consistent across all threads when the monitor is released, and that can only be guaranteed with synchronized (or one of the Atomic classes), not just a lock.
The other reason not to use synchronized(this) is because it exposes implementation details. Suddenly external code can lock (forever) on your mutex or notify it. Best is to have a private field holding a dummy instance or an otherwise inaccessible instance (no getter), acting as the mutex.
I can’t say that I’ve ever really run into other objects making an unauthorized grab of some other instance’s monitor. I just mark methods as ‘synchronized’, everyone stays in their own yard, and everyone’s happy.
The same could be said about field visibility. I like to code defensively 
I try to avoid using ‘synchronized’, especially in performance critical code.
If your program is single-threaded, synchronization is basically a no-op in a modern JVM. Of course not sharing state is also a legit way of preventing that kind of overhead.
Lock-free is your friend. Esp. lock free stuff others have written for you. Rough rule of thumb (which mean it’s wrong quite a bit) is to be lock-free except under very heavy contention…and you never want to be in a heavy contention situation. Therefore, synchronized should be considered very stinky and you should wonder if you’ve gone horribly wrong somewhere if you write it.