Is Alien Flux single-threaded?

[20thCenturyBoy]

Some people (e.g. on the Gage http://java.dnsalias.com front page) say that multiple threads are not necessary in the typical action Java game. However lots of books and articles seem to use threads for various systems (animation, sound etc). What is the "best" advice for smooth gaming? As an aside, is Alien Flux single or multi-threaded?

20thCB

[Herkules]

IIRC, AlienFlux has a singel-threaded main loop.

Think of this: why have an animation thread when you need to synchronize every frame anyway?

[20thCenturyBoy]

Think of this: why have an animation thread when you need to synchronize every frame anyway?  

I don't know, I'm a newbie, maybe you could explain further?  

Games published by our own members! Check 'em out!

[princec]

Alien Flux is single threaded, as are all my trivial single player games going to be.

Main loop does something like this:

while (!finished) {
readInput();
think();
render();
waitForFrame();
}

Cas

[Herkules]

Whenever a frame has to be rendered, you have to have everything right in place. Logic has to be done, motions performed, animations animated. If done multithreaded, you would just have to make sure that each thread reached the ready-to-render state. So they have to be synchronized at one certain point. That means MT does not give you any advantage any more.

MT typically comes into play when dealing with the network (my domain ). Network message arrive any time and you don't want to be your ping values being dependant on framerate. So there's typically one thread receiving network messages.

Again, most information received from the network cannot be evaluated right in place but have to be synchronized with the gameloop again (many 3D engines get REALLY pissed off when modifying transforms while they are rendering ).

General: MT is always difficult. Avoid if you can. In games, you can.

[blahblahblahh]

General: MT is always difficult. Avoid if you can. In games, you can.

! That sounds very wrong to me. MT isn't difficult at all, really. And there's no reason to avoid it in general programming.

The situation with games dev is that you have specific reasons for wanting to avoid non-deterministic timing behaviours, and at the same time you derive no advantage from OS-provided multi threading because it's quite easy for you to write your own real-time thread scheduler that is at least as effective as the OS.

In a perfect world, all games would be MT IMHO. A couple of things would be needed though, including:
- an OS switch "please use an RT scheduler on my thread group"
- Sun fixing (ie preferably removing) their "innate" multi-threading.

The latter is a particular problem on windows, where the "secret" AWT threads not only screw up your programming but in games also make it extremely difficult to guarantee stuff happens at even approximately the right time.

I've seen people do MT in java whilst swearing blind they weren't, and without using the Thread or Runnable anywhere in source; they had inadvertently found out how to hijack the innate AWT thread, and were simultaneously using their main thread. It was fascinating, but also no surprise that they had lots of very weird bugs no-one could tell them how to fix.

If you had a really good OS (they do exist, but you can't generally buy them as consumer OS's) then you could go MT no problem. The reality of games programming today is that there are outstanding problems with the timing of threads especially in java (read Sun's API docs on threading - you will note they make statement like "this method offers no guarantees that anything will happen at any particular time or frequency").

[princec]

Threads are still the wrong tools. You actually want parallel tasks, which is a very different kettle of fish.

Cas

[Herkules]

MT isn't difficult at all, really.

Oh yes, it is. As soon as you have to handle synchronized/wait/notify, it gets weird and needs are VERY thorough understanding of what is going on!

Sporadic deadlocks are bastards!!

[blahblahblahh]

But...in most cases you don't ever have to go near wait and notify.

For instance, I've been doing MT java coding heavily for the last 6 years, and it's literally been years since I last used wait + notify. Synchronized is a different matter entirely, but is actually a very simple concept once you understand it (I have ongoing debates with a friend who believes that some people just aren't mentally capable of grasping the concept without huge difficulty - he reckons it's like "being good at Maths": some people just can't visualize it properly. I'm open-minded but not convinced yet ).

The only time I can remember really making good use of wait/notify was as the core for a MUD server, where it had thread-per-client and all client threads waited on the server ticking clock. Each tick, it simple called notifyAll as a convenient way (in just a few lines of code) of approximately synchronizing all clients to the same "fair" clock-tick.

All the producer/consumer examples that are common on uni courses and java websites for instance are a gross deception - these are rarely used in real life (there isn't much software that uses multi-threaded pipelines these days - and even then there are alternative algorithms to achieve the same features). They're great for teaching people a practical use for wait/notify, but ... I can't remember seeing one in a real life system (apart from the odd academic distributed system, and occasional academic/research OS).

What about you - do you see a lot of wait/notify "in the wild"? I've always assumed some industries use them heavily, but then again perhaps they aren't using java for that level of their systems?

[20thCenturyBoy]

General: MT is always difficult. Avoid if you can. In games, you can.

Hurrah! One less thing to worry about  

Games published by our own members! Check 'em out!

[swpalmer]

blah³ , I was with you until you mentioned no wait or notify.  I find that free-running threads that never block are often a problem.  I can only assume that you aren't explicitly using wait, but are relying on blocking I/O operations?

Edit:  never mind  - I'm being brain dead... synchronized of course is another form of blocking that can be effective without wait/notify.

Multi-threading can make some thing much easier in some games though.  Fast Action "twitch" games are usually not as suited though.

[blahblahblahh]

Edit:  never mind  - I'm being brain dead... synchronized of course is another form of blocking that can be effective without wait/notify.

*I* should have put it like that and made myself less obscure.

Synchronized is either a "crude" form of blocking or a "simplified, higher-level" form - depending upon whom you talk to . Personally, I'm in the latter group, whereas most (all?) of my lecturers were in the former...

Personally I find that for the vast majority of real cases you don't need the extra control offered by wait/notify, and that synchronized blocks achieve all you need. Although at first I found the quite unconvential keyword a bit daunting (partly that was the fault of said lecturers - who badmouthed it a lot) over time I've come to realise it is a truly excellent programming-language feature - a bit of gifted design work by the original architects. If you've done much C multi-threading [1], my guess is that it's like going from malloc to automatic transparent GC - lots of boilerplate code you used to write just disappears, and 99% of the time you don't miss it

[1] - I haven't done multi-threading in C for many years, and even then not much. I'm sure there are good high-level libs for this by now, but I recall lots of relatively low-level fiddling compared to e.g. synchronized in java...

[princec]

I wish synchronized was extended with a nanosecond timeout and could throw a RuntimeException if it didnt get a lock in time :/

Cas

[Orangy Tang]

Doing a multi-threaded app is easy, its debugging it thats the hard part.

[blahblahblahh]

I wish synchronized was extended with a nanosecond timeout and could throw a RuntimeException if it didnt get a lock in time :/

Cas

This is what I mean about it being nice and simple but at the cost of a lot of power.

I see where you're coming from on that, and I would definitely move a JDC vote to an RFE for this post-structs .

But it would be quite a complex change. You'd either have to add an extra code-block to the syntax, as well as the extra args, or else add some new API to the core libraries - and ask for developers to update all legacy code that depends upon code-analysis of the existence/location of the synchronized keyword. (I would guess, going on past examples, that the latter would be enough to cause Sun to refuse it - they seem particularly keen not to upset large users of java with big chunks of legacy code by adding non-forwards-compatible changes).

In fact, I can't see how you could do it sensibly with an API, since java doesn't support closures etc, so you can't embed "the code I want you to run" into a variable to pass to the API; you'd have to do a Runnable-esque approach which IMHO is prohibitively ugly, and only works at a class level.

So...it would need to be a syntax change, something like:

1   2   3   4   5   6   7   8   9   10   11

public void something() {   synchronized( this )   {     //...do something   }   timeout( 10000 )   {     System.out.println( "I waited 10000 nanoseconds but couldn't get the lock" );    } }

Nice to wish for, but I'd say there isn't a snowball's chance in hell we'd ever get it . Perhaps in whatever language comes next, after Java and C#? Looking at the timeline C - C++ - Java, we're due for another leap forward sometime in the next 1-3 years ...although mayble it'll be another skunkworks project most people don't hear about for the first couple of years.

[cfmdobbie]

I would definitely move a JDC vote to an RFE for this post-structs .

/me waits for hell to freeze over...