Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  [synchronized(this) { } ?]  (Read 4127 times)
0 Members and 1 Guest are viewing this topic.
Offline GabrielBailey74
« Posted 2012-11-04 03:10:00 »

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?

1  
2  
synchronized(this) {
}


Hope someone can help, thanks.

Offline ra4king

JGO Kernel


Medals: 337
Projects: 2
Exp: 5 years


I'm the King!


« Reply #1 - Posted 2012-11-04 03:42:58 »

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.

Offline GabrielBailey74
« Reply #2 - Posted 2012-11-04 03:59:47 »

Thanks, guess i'll look up on it some more, remove it from my game.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« Reply #3 - Posted 2012-11-04 04:01:28 »

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.
I don't even get why you would want to synchronize your game.  Huh

Smiley
Offline theagentd
« Reply #4 - Posted 2012-11-04 04:13:02 »

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.
I don't even get why you would want to synchronize your game.  Huh
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.

Myomyomyo.
Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« Reply #5 - Posted 2012-11-04 04:14:19 »

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.
I don't even get why you would want to synchronize your game.  Huh
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.  Grin

Smiley
Offline SHC
« Reply #6 - Posted 2012-11-04 04:19:55 »

You may want to see this question.

http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java

Offline GabrielBailey74
« Reply #7 - Posted 2012-11-04 04:24:14 »

lol, that's the post I was looking at right after I replied to ra4king. Shocked
Thanks guys.

Offline theagentd
« Reply #8 - Posted 2012-11-04 04:26:34 »

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.

Myomyomyo.
Offline GabrielBailey74
« Reply #9 - Posted 2012-11-04 04:29:25 »

Geeze, thanks theagentd.

I removed about 5 synchronized statements from the game (just posted it in WIP), seems my fps went up Grin
(guess i had no idea about sync statements, will reserve for threads only >.<)

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Agro
« Reply #10 - Posted 2012-11-04 04:32:47 »

Wouldn't syncronhized threads block/speed up your game depending on the usage?

Offline theagentd
« Reply #11 - Posted 2012-11-04 04:34:15 »

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.

Myomyomyo.
Offline GabrielBailey74
« Reply #12 - Posted 2012-11-04 04:44:34 »

Wouldn't syncronhized threads block/speed up your game depending on the usage?

That's what I thought it was doing at first Emo

Offline sproingie

JGO Kernel


Medals: 202



« Reply #13 - Posted 2012-11-04 05:06:29 »

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.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #14 - Posted 2012-11-04 05:10:59 »

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.

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

JGO Kernel


Medals: 202



« Reply #15 - Posted 2012-11-04 05:20:41 »

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.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #16 - Posted 2012-11-04 05:23:51 »

The same could be said about field visibility. I like to code defensively Smiley

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

JGO Kernel


Medals: 337
Projects: 2
Exp: 5 years


I'm the King!


« Reply #17 - Posted 2012-11-04 05:27:37 »

I try to avoid using 'synchronized', especially in performance critical code.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #18 - Posted 2012-11-04 05:43:08 »

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.
Online Roquen
« Reply #19 - Posted 2012-11-04 07:39:15 »

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.
Offline nsigma
« Reply #20 - Posted 2012-11-04 13:08:18 »

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.

If you're talking about implementation of the Lock interface, then that's wrong.  The spec says that all implementations must enforce the same memory barrier semantics.  Not that that can be guaranteed from an interface, but you can guarantee that the built-in implementations will adhere to it.

Therefore, synchronized should be considered very stinky and you should wonder if you've gone horribly wrong somewhere if you write it.

Couldn't agree more!  Learn to use lock-free mechanisms, particularly lock-free queues, for passing information around.  Praxis' architecture is designed in this way - there are almost no locks anywhere in the code base (except a couple of places where they're enforced by 3rd party libs).  The first part of this blog post on its architecture (and the linked to post by Ross Bencina) may explain some reasons this is a good idea in general, particularly where you want consistent timing (eg. framerate!)

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline KittenKoder

Senior Member


Medals: 7



« Reply #21 - Posted 2012-11-04 13:13:24 »

Vectors are about the only time I use it, and that's because I use vectors to communicate between threads. Otherwise I avoid it, you can manage locking inside the class if the object really needs it.

I am no one else.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #22 - Posted 2012-11-04 17:29:57 »

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.

If you're talking about implementation of the Lock interface, then that's wrong.  The spec says that all implementations must enforce the same memory barrier semantics.  Not that that can be guaranteed from an interface, but you can guarantee that the built-in implementations will adhere to it.

All Lock implementations must enforce the same memory synchronization semantics as provided by the built-in monitor lock, as described in section 17.4 of The Java™ Language Specification:

    A successful lock operation has the same memory synchronization effects as a successful Lock action.
    A successful unlock operation has the same memory synchronization effects as a successful Unlock action.

Unsuccessful locking and unlocking operations, and reentrant locking/unlocking operations, do not require any memory synchronization effects.

Huh, I stand corrected.  I was under the impression that the monitor semantics only applied to the state of the Lock itself, but the javadoc is pretty clear in referencing the JLS.  That's interesting, because I have screwed myself with out-of-order updates when using a Lock, which went away when I synchronized instead.  Perhaps I let go of the lock too soon... I'd check the code, but I don't think I ever committed the broken version.  Oh well, more anecdotal evidence that multithreading is hard.   Undecided
Offline delt0r

JGO Knight


Medals: 26
Exp: 18 years


Computers can do that?


« Reply #23 - Posted 2012-11-04 22:29:08 »

I don't use synchronize anymore. Just use the stuff in java.util.concurrent.*, its typically the same speed or better and you have something that is generally easier to use.

I have no special talents. I am only passionately curious.--Albert Einstein
Online Roquen
« Reply #24 - Posted 2012-11-05 09:55:34 »

I have a strong tendency to have strong isolation of "ownership" notions which requires virtually nothing special.  I'd say the majority of my "sync" is via volatile.  The most used concurrent data-structure is a fixed-length single producer/single consumer circular list (wait-free).  Toss in some atomic types and that covers the majority of concurrent communication.  But hey, maybe I don't get out enough.
Offline Spasi
« Reply #25 - Posted 2012-11-05 11:30:44 »

The most used concurrent data-structure is a fixed-length single producer/single consumer circular list (wait-free).  Toss in some atomic types and that covers the majority of concurrent communication.

Disruptor or something custom?
Offline ra4king

JGO Kernel


Medals: 337
Projects: 2
Exp: 5 years


I'm the King!


« Reply #26 - Posted 2012-11-06 00:45:27 »

I just use a ConcurrentLinkedQueue if I ever need to communicate a list of events/information between threads Smiley

Offline Spasi
« Reply #27 - Posted 2012-11-06 01:41:39 »

I just use a ConcurrentLinkedQueue

Be careful with that. CLQ is unbounded (no way to create back pressure) and the tail/head references sharing the same cache line causes unnecessary contention.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #28 - Posted 2012-11-06 01:47:00 »

To say nothing of ConcurrentLinkedQueue not having any blocking operations.  I prefer ArrayBlockingQueue myself, or SynchronousQueue when I need a synchronization point (which is pretty rare)
Offline ra4king

JGO Kernel


Medals: 337
Projects: 2
Exp: 5 years


I'm the King!


« Reply #29 - Posted 2012-11-06 02:00:24 »

I just use a ConcurrentLinkedQueue

Be careful with that. CLQ is unbounded (no way to create back pressure) and the tail/head references sharing the same cache line causes unnecessary contention.
So....err......in English? Tongue

Pages: [1] 2
  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.

Riven (7 views)
2014-07-29 12:53:52

Dwinin (7 views)
2014-07-29 10:59:34

E.R. Fleming (23 views)
2014-07-29 03:07:13

E.R. Fleming (9 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (51 views)
2014-07-17 23:47:54
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!