### GameDev Marketplace

#### Men's i.make.games T-shirt

$20$15

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

4 replies to this topic

### #1Flopid  Members

Posted 17 June 2013 - 12:28 PM

Hello. I've got back into programing with OpenGL (JOGL) since it's so portable. I wanted to make my engine multithreaded so I've read up a Java trail about concurency and stumbled on something interesting here:

How can both threads enter bow if it is synchronized, so that as the article says, they will both be stuck at bowback? Is it possible for threads to enter synchronized methods at the exact same time, but not right after eachother then or wha?

This would completely mess up the whole sync identifier, since threads can pretty much always call the method at the same time...

Really weird, watcha think?

### #2frob  Moderators

Posted 17 June 2013 - 01:28 PM

Synchronized methods block the object from entering any other synchronized method of the object until the earlier one is finished.

In their example:

Synchronized function on Alphonse is called; Alphonse gets locked until completion.

Synchronized function on Gaston is galled; Gaston gets locked until completion.

Gaston calls synchronized function on Alphonse; it blocks until the lock is released.

Alphonse calls synchronized function on Gaston; it blocks until the lock is released.

I wanted to make my engine multithreaded

Hopefully your little piece of example code above will change your mind.

You really want to AVOID MULTITHREADING inside your engine until you have already mastered many other areas of game development. Eventually you will start with using asynchronous methods and callbacks.  Then you will come to making a single specific algorithm take advantage of multiprocessing when it is available.

Most experienced developers see a problem that suggests multithreading, cry on the inside, and then use it as an opportunity to either implement a naively asynchronous solution or implement a piece-wise sequential solution that avoids all the uncertainties of multiprocessing.

Writing correct solutions to problems that require serious use of multiprocessing is difficult. Usually it is easier to find alternative solutions than to find the subtle demons in buggy multiprocessing code.

Edited by frob, 17 June 2013 - 01:28 PM.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

### #3Flopid  Members

Posted 17 June 2013 - 03:10 PM

Well I understand completely what is happening now. I did not really think that Java would obliterate synchronization. Thanks for the clarification frob!!!

You really want to AVOID MULTITHREADING inside your engine until you have already mastered many other areas of game development.

I am kind of thinking ahead when in the future I would have a scene with many objects appearing and dissapearing or changing shapes. For things like buffers in that instance multithreading would be a great boost (think OpenCL oh noes). I also think that starting to thread simple code is much easier than threading at the end where u can miss something and might have to debug... for a while : )

Again many thanks for your replies and have a great day!

### #4swiftcoder  Senior Moderators

Posted 18 June 2013 - 12:38 AM

I also think that starting to thread simple code is much easier than threading at the end where u can miss something and might have to debug... for a while : )

Or you could miss something, and end up having to debug from the start.

And by the way, debuggers don't really work in multithreaded code. Nor do log/print statements.

The only realistic way to approach multithreading is from a purely mathematical/theoretical standpoint.

Multithreading has nothing to do with either Java or graphics. Nor "fun", for that matter.

Edited by swiftcoder, 18 June 2013 - 12:39 AM.

Tristam MacDonald - Software Engineer @ Amazon - [swiftcoding] [GitHub]

### #5SimonForsman  Members

Posted 18 June 2013 - 02:55 AM

I also think that starting to thread simple code is much easier than threading at the end where u can miss something and might have to debug... for a while : )

Or you could miss something, and end up having to debug from the start.

And by the way, debuggers don't really work in multithreaded code. Nor do log/print statements.

The only realistic way to approach multithreading is from a purely mathematical/theoretical standpoint.

Multithreading has nothing to do with either Java or graphics. Nor "fun", for that matter.

That depends on your definition of "fun".

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.