Sign in to follow this  
Flopid

Java Deadlock Question

Recommended Posts

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:

 

http://docs.oracle.com/javase/tutorial/essential/concurrency/deadlock.html

 

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?

Share this post


Link to post
Share on other sites

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.

Deadlock.

 

 

 

 


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

Share this post


Link to post
Share on other sites

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 : )

 

Plus I am just doing this for fun to learn more about Java and graphics.

 

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

Share this post


Link to post
Share on other sites

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.

Plus I am just doing this for fun to learn more about Java and graphics.

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

Share this post


Link to post
Share on other sites

 

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.

Plus I am just doing this for fun to learn more about Java and graphics.

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

 

 

That depends on your definition of "fun".

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this