Java Deadlock Question

Started by
3 comments, last by SimonForsman 10 years, 10 months ago

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?

Advertisement

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.

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!

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.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.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.

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".

[size="1"]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!

This topic is closed to new replies.

Advertisement