Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
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  
  Several TimerTasks or just one?  (Read 2168 times)
0 Members and 1 Guest are viewing this topic.
Archimedes
Guest
« Posted 2003-07-13 09:59:39 »

Hi,

I'd like to do several timed tasks in a game. Task ExA shall be issued every second, task ExB 10 times a second, etc.
What's more efficient: to use several TimerTask classes for each of them (they run in an own Thread then) or to use one TimerTask class which internally does all the different tasks, controlled by variable counters?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
class ExA extends java.util.TimerTask
{
  run() {..}
}

--

java.util.Timer timer = new java.util.Timer();
timer.schedule(new ExA(), 1, 1000/ 1);  // Call it  1 times a second.
timer.schedule(new ExB(), 1, 1000/10);  // Call it 10 times a second.
timer.schedule(new ExC(), 1, 1000/20);  // Call it 20 times a second.


In former times (C/C++) I used one timer which did all stuff by using counters.
However, how are things in Java today? Is there a big overhead to create severak small TimerTasks, or is Thread handling in Java a totally natural and lightning fast operation?

While the different TimerTasks are much more elegant to implement, I'm afraid it involves an overhead which I don't like. :-)

Thanks.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2003-07-13 10:39:51 »

Don't use timer tasks or threads. Just write a simple scheduling class that performs things periodically (using System.currentTimeMillis() if that's accurate enough) and is called once per iteration of your main loop.

Cas Smiley

Offline troggan

Junior Member




no guts no glory


« Reply #2 - Posted 2003-07-13 11:10:07 »

Why don't use Threads Huh ? I tested Threads/Timers and I see the following :
Thread: 5% CPU Load
Timer: 100% CPU Load  (With the hidden Perf-Thingie)

Troggan


(http://www.wannawork.de) - Will work for food
(http://tvbrowser.org) - Java EPG
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline MGodehardt

Junior Member




why does the chicken cross the road?


« Reply #3 - Posted 2003-09-02 00:19:15 »

Games have 100% CPU load, its a must have, the System will never go to sleep mode or reduce CPU speed.

Check some games ( like Ultima Online ), when i start it in a window i have 100% CPU load.

So u get 100% of the CPU, u want a Realtime Game, so u need all the power u can get  Cool
Offline tom
« Reply #4 - Posted 2003-09-02 00:55:47 »

Threads in java is supposed to be ligthweight. So there should be very little performance overhead in using 3 threads instead of 1.

Offline MGodehardt

Junior Member




why does the chicken cross the road?


« Reply #5 - Posted 2003-09-02 13:00:05 »

Under Win9x threads are scheduled by the timer which has a 50ms resolution. So maximum FPS will be 20FPS if u go higher your game will flicker and lag, trust me i am a professional game developer.

Next Problem with Threads are the synchronized things, even if u do the game physics in multiple threads you have to sync to render method, otherwise you will change variables in the middle of a render.

I use my own pseudo Thread scheduler, i called it a GameEvent.

Those GameEvents have a counter ( how many times should the Event be called ) and a delay ( how many time between calls to Event )

I have 1 Vector with all events, i put a event for a scroller in it, it gets called every 50ms and the counter is -1 which means it will never expire.

I get a very very smooth scrolling with it.
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #6 - Posted 2003-09-02 13:24:12 »

Threading might not have a huge overhead, but writing thread safe code is a LOT harder than just going with one thread.

And considering you only benefit from using multiple threads when doing blocking IO operations or using a multi-processor system, there's really not much speaking for multi-threading any more.

Play Minecraft!
Online kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #7 - Posted 2003-09-02 13:33:39 »

Not that I disagree in this case, but threading can often help in modular code design. If you have two sections of your code that logically run at the same time then using two threads can often make the code far easier to comprehend and if the interface between these two section is clearly defined then synchronisation isn't really that much of a difficulty.

However, since we're in "Performance Tuning" threading is pretty much a no no.

The CPU usage thing is a red herring, the 100% usage fades away as other things want to use the processor. It just makes sense for game that if they can get 100% of the CPU time, to take it. Smiley

Kev

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #8 - Posted 2003-09-03 00:11:19 »

Quote
Don't use timer tasks or threads. Just write a simple scheduling class that performs things periodically (using System.currentTimeMillis() if that's accurate enough) and is called once per iteration of your main loop.


Time to chime in with some recent experiences with TimerTasks...

They're actually quite a nice idea, but leave you with the impression that the API was started by someone who left Sun shortly afterwards, and never quite finished the job. Apart from their flaws, they are very effective for tasks where your timing granularity is measured in large numbers of milliseconds.

They're excellent for when you actually need to schedule things at "minutes past the hour" etc, because they can take a Date as the start time etc. This is also nice when you happen to be working in a multi-locale app, and being able to pass in Date's without further worry is a relief (I *HATE* Date).

Unfortunately, they're bloody dangerous. Witness the method: Timer.schedule( TimerTask t, Date starttime, long period ). starttime here is the Date (recall that Java names a time in milliseconds a "Date" Arggh!) that you want the task to be first scheduled. Period is, obviously, the period. This makes something like  "every 5 minutes, offset = 2" (i.e. 7, 12, 17 etc) easy.

Except...The design of the API is such that if Date is in the past, it throws a runtime (i.e. your compiler won't force you catch it) Exception. This is a disaster waiting to happen if you ever get pre-empted and by the time the method body is executed, that Date has passed...

Another PITA is that you cannot "reschedule( TimerTask )" nor - more usefully - "TimerTask.reschedule( blah blah blah )". This means you have to keep explicitly cancelling your tasks, and maintaining extra state that is otherwise pointless, but for the fact that the API implementor didn't quite get around to adding the reschedule method.

Anyway, my conclusion is that I'm continuing to use them as a quick-n-clean long-term scheduler that usually schedules in minutes, sometimes in seconds, and very rarely (..but this is really getting dangerous thanks to that Exception..) in millis. I know the problems with the API, and other than that it's a bunch of code I don't have to debug, that works quite nicely (note the easy integration with Runnable's). Once I've got some extra time (or incoming staff Smiley) I'll replace it with a slightly more feature-rich (and hence actually useful in practical situations!) task-scheduler (e.g. reschedule()). I'm also hoping that they'll get deprecated and replaced in 1.5 with something more useful (I get the feeling that several improved clock/timer/scheduling things will appear pretty soon, probably all in one go)

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #9 - Posted 2003-09-17 01:12:49 »

Quote

They're actually quite a nice idea, but leave you with the impression that the API was started by someone who left Sun shortly afterwards, and never quite finished the job. Apart from their flaws, they are very effective for tasks where your timing granularity is measured in large numbers of milliseconds.


One step at a time:

"Thank you for reporting this issue.

We have determined that this report is a new bug and entered the bug into our
internal bug tracking system under Bug Id: 4923634
...
synopsis : TimerTask should be an interface, or else take an interface as argument
description : A DESCRIPTION OF THE REQUEST :
TimerTask needs an additional constructor, which takes a Runnable as argument.
...
Add an extra constructor to TimerTask that takes a Runnable as argument. (this guarantees that the class has a .run() method EXACTLY as per TimerTask)"

malloc will be first against the wall when the revolution comes...
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.

Riven (10 views)
2014-07-29 18:09:19

Riven (8 views)
2014-07-29 18:08:52

Dwinin (8 views)
2014-07-29 10:59:34

E.R. Fleming (25 views)
2014-07-29 03:07:13

E.R. Fleming (10 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!