Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Thread Problem?  (Read 1121 times)
0 Members and 1 Guest are viewing this topic.
Offline OttoMeier

Senior Member


Medals: 4
Projects: 1



« Posted 2010-10-10 19:40:41 »

With the following code i sometimes an excption:
java.lang.IndexOutOfBoundsException: Index: 20, Size: 20 at the get(i) line

1  
2  
3  
4  
5  
6  
7  
public void processCollisons(Octree aOctree,List<LeafCollisionSupportIF> leafList){
...
for (int i=leafList.size()-1; i>=0;i--){
    LeafCollisionSupportIF leaf=aLeafList.get(i);
    ...
}
...


how is that possible? I think its a Thread problem but how to debug this. I already tryed a synronized Collection (
1  
Collections.synchronizedList(new ArrayList<LeafCollisionSupportIF>())
) and make the method synchronized but without success.
I also cant reproduce this in a simple unittest.
Any tips how to debug this?

Offline Nate

JGO Kernel


Medals: 147
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #1 - Posted 2010-10-11 00:26:37 »

Synchronizing the list protects the internal state of the list. If you make two calls to the list, eg one size and one get, there is time between the calls that other threads can call methods on the collection. That is happening to you:

1  
2  
3  
for (int i=leafList.size()-1; i>=0;i--){
    // Before this next line, some other thread removes from leafList.
   LeafCollisionSupportIF leaf=leafList.get(i);


Synchronizing the method protects two threads from entering the method at the same time. If the code removing from the list is in a different method that is not synchronized, this doesn't protect access to the list. Remember synchronizing the method is the same as wrapping the method contents with "synchronized (this) {...}" (or "synchronized (Whatever.class) {...}" for static methods).

Synchronize on the list to protect the entire block of code:

1  
2  
3  
4  
synchronized (leafList) {
    for (int i=leafList.size()-1; i>=0;i--){
        LeafCollisionSupportIF leaf=leafList.get(i);
}


Does your app really need multiple threads? Sometimes you can simplify things, eg, say you have a game thread and a network thread. Read in objects on the network thread and store them for processing on the game thread to avoid any synchronization issues.

Offline OttoMeier

Senior Member


Medals: 4
Projects: 1



« Reply #2 - Posted 2010-10-11 15:53:28 »

i use the default jogl setup (Animator GLPanel) so i think i have atleast 3 threads: mainthread, EDT and Animator(render loop) right?

i tryed to illustrate the problem in the following picture
engine thread problem picture
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Nate

JGO Kernel


Medals: 147
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #3 - Posted 2010-10-11 20:51:30 »

Eh, I use LWJGL. I have one thread for rendering and one for network.

My suggestions still stand: either synchronize properly, eliminate using multiple threads, or move the concurrent modifications to occur in the same thread.

Note you must synchronize on the list in both threads, not just where shown above.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #4 - Posted 2010-10-11 21:02:43 »

Eh, I use LWJGL. I have one thread for rendering and one for network.

My suggestions still stand: either synchronize properly, eliminate using multiple threads, or move the concurrent modifications to occur in the same thread.

Note you must synchronize on the list in both threads, not just where shown above.
To echo this -

I will usually make a "pending" version of each list that gets processed in the main game loop. That means that any other threads never actually change game data directly, instead they put their change into the pending list. This not only avoids most possible issues but it also helps maintain sanity - your stack traces will make more sense (all being on the same thread) and you can keep everything as "deterministic" as possible.

See my work:
OTC Software
Offline ddyer

Senior Member


Medals: 5



« Reply #5 - Posted 2010-10-12 07:39:59 »

Problems like this are virtually impossible to eliminate as long as threads are in use.  The "standard"
architecture of a java game will have at least 4 threads running freely through all your data structures.

(1) the game main thread
(2) the mouse / keyboard event handler
(3) the network communications handler
(4) the screen refresh

That is complete madness.  You must have one thread that does all the work, and has events from
all other sources presented in a disciplined way through queues.
Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #6 - Posted 2010-10-12 07:54:56 »

An easier way to deal with threads and communications between them is have a look at java.util.concurrent*. I often have a ConcurrentLinkedQueue that one thread adds things too and another thread that removes them. The nice thing about this is, that having two threads that add objects to the queue requires not extra synchronization. There are also things like fairness that can be set with the concurrent package which is tricky to implement with monitors.

Personally I use threads quite a bit. I find java the easiest language to deal with threads, and of late the performance is very good.

It should be noted there are a number of extra tricks that can be done. But IMO java.util.concurrent* has made most of them obsolete.

I have no special talents. I am only passionately curious.--Albert Einstein
Pages: [1]
  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.

BurntPizza (22 views)
2014-09-19 03:14:18

Dwinin (35 views)
2014-09-12 09:08:26

Norakomi (62 views)
2014-09-10 13:57:51

TehJavaDev (88 views)
2014-09-10 06:39:09

Tekkerue (44 views)
2014-09-09 02:24:56

mitcheeb (65 views)
2014-09-08 06:06:29

BurntPizza (47 views)
2014-09-07 01:13:42

Longarmx (35 views)
2014-09-07 01:12:14

Longarmx (40 views)
2014-09-07 01:11:22

Longarmx (36 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!