🔒 Locked

Multithreading Balance.

Started by gimp May 11, 2004 at 12:47 AM 3 replies 450+ views

Original Post

May 11, 2004 at 12:47 AM

I''m thinking about using a pool of threads to load my resources. So far I do things like: -OGG Decompression -Voxel Skinning(reasonbly costly) -Simple model and texture loading When I need to load or generate a resource at runtime (streaming) that would cause undue stutter in the frames most people turn to threading. The way I see it though if you game is running at say 80% of the processor time already and you load a thread to use up the other 20% I''d assume you would need a reliable sleep mechanism to make up the renderer right before the next frame so your frame delivery is smooth. How is this handled? Sure I can start another thread(s) and set them to do this work at a lower system priority but how do I know their quanta won''t overlap the next frames start time required to maintain say 60fps?

kuphryn

May 11, 2004 at 2:04 AM

Raise the priority of the render threads.

Kuphryn

Jan Wassenberg

105

Jan Wassenberg

May 12, 2004 at 10:21 AM

> Raise the priority of the render thread
hehe

no good if the timeslice (aka quantum), i.e. how long a thread is allowed to run, is longer than the time until the next render.

I don''t think that''s feasible without OS support (changing scheduler parameters). User-level threads suck here, because you have deadlines. So why not go the poor man''s route, split your work into smaller tasks (say 1 iteration of a loop), and work them off until a certain period of time (how much you were planning to give the task) has elapsed?


main loop:
  render
  // assume we have say 10 ms here to do stuff, while card is transferring stuff+rendering
  while time bugdet not exhausted
    process work unit

The problem of what to do if your little "thread" falls behind remains; slow down the target framerate, or just let it stutter.

gimp

Author

gimp

May 18, 2004 at 2:11 AM

What about calling some kind of yeild at regular intervals of the low priority work so that if the renderer wants to kick off and your read ahead buffer is decoding voxel files it''ll just yeild every x chunks of work so that the chance that you''ll meet the render time frame cutoff will be minimised.

I think I remember that NT workstation 4.0 (probably also XP) quantum is 10ms. A 60fps game starts a new frame every 16.7ms.

I full quantum will be used if the task takes that long(or longer). Would yeilding over and over have any negative impact?

ggs

May 18, 2004 at 11:58 AM

quote:
Original post by kuphryn
Raise the priority of the render threads.

No, you should lower the priority of the worker threads by a bit. Thus the render thread will (almost)always get a timeslice over the worker thread and the worker thread will occasionally be promoted so it can get a timeslice.

Once your worker thread has finished doing a job, spin on this type of code:

while ( workQueue.isEmpty() ) {sleep(0);}

The 'sleep(0)' bit causes the worker thread to completely yield its timeslice and the 'workQueue' is a queue of items to process. You also need some code to gracefully handle termination requests.

I would look up on how the .NET framework implements threadpools and other threadpool documentation. With .NET & Reflector, you can directly inspect how Microsoft implemented the threadpooling system biult into the .net framework.

Note:Suspending a thread is generally very bad behaviour, because of the issue of deadlocks.

[edited by - ggs on May 18, 2004 1:01:10 PM]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.