I think I may be able to add something useful to this thread.
Even up to the last page I keep seeing posts talking about throwing in threadding.
Seriously, it introduces wierdness.
lots and lots of it.
People keep talking about threading as if it's something trivial... and if your task suits it and you set out to use threads from day one it can be ... not so bad.
But you can get bugs in a threaded program that would never crop up in non threaded ones.
Deadlocks are just the start of it.
Now I'm personally only familiar with threading in java, not so much in C but here's a simple trial for anyone who feels like seeing something interesting and has javac handy.
Create a program with 2 threads, nothing fancy, you should be able to find tutorials online that show you how.
Now create a variable.
int Counter = 0;
now have both your threads do the same thing.
Have each thread do a loop where it increments Counter 10,000,000 times.
No special threading tricks. just unguarded simple ++ .
For(int i=0;i<10000000;i++)
{
Counter++;
}
At the end of the program your programmer sense would tell you that Counter should be equal to 20,000,000.
It won't be equal to that unless the JVM has been changed a lot recently.
because strange things happen then 2 threads try to mess with the same data.
one thread starts to increment the data say from 10 to 11, looses its hold on the processor, the other thread increments it 10 times up to 20 and then the first thread gets back it's hold on the processor and finishes incrementing from 10 to 11 and 10 increments have disappeared.
Or if you have a game where the players location is kept as a pair of values [X,Y] and the player loses if they step on the trap at [0,0].
Say at some point in your maze you have the player move from [1,0] to [0,1] .
but you have 2 threads dealing with it, one thread testing if the player is at the end of the maze and other environment stuff and another thread for dealing with taking in user input and altering the players state.
1:the player starts to move from [1,0] to [0,1].
2:the "player" thread changes the variable which holds the X position from 1 to 0.
3:the "player" thread loses control of the processor.
4:the "environment" thread tests to see if the player is on the trap... well X=0 and Y=0 so the player is on the trap.
5:game over.player gets dropped into the spike pit.
these are just trivial examples but its a big problem you have to deal with whenever threading is involved.
Now imagine you're trying to split processing in DF.
one thread starts to remove a burning object as it poofs out of existance.
another thread is pathing for a dwarf looking for that item.
The thread that's removing the item deallocates the memory used for the objects description and characteristics to make room in memory.
meanwhile pathing thread finds that item in the array, starts to read it's location, yes it's closest, goes to check it's characteristics to make sure it's suitable[BANG! seg fault! crash! game broken.]
trying to turn a non threadded game into a threadded game in anything but very very limited ways would be a nightmare.
Author
Topic: Lag discussion, how to address it and be generally helpful to Toady/Threetoe (Read 18134 times)