plib-users

[Plib-users] Multithreading in FG

[Hemalatha S. <hem...@re...>]

 =A0Hi,=0AWe are using Flightgear version 0.9.4, in which we are trying to =
implement multi-threading. In one thread, processing of next frame will be =
done and in the other, rendering of the previous frame. Here, fgMainLoop() =
is split into two threads, all the processing before calling fgRenderFrame(=
) in one thread, i.e. subsystem updates, input/output updates, tile manager=
 updates,  etc., and fgRenderFrame() in the other thread.=0A=0AIs this the =
correct method of splitting processing and rendering of frame data?=0A=0AWe=
 are using the below to create a thread:=0AhThread[1] =3D CreateThread(NULL=
,0,(LPTHREAD_START_ROUTINE)fgRenderFrame1,NULL,0,&dwID[1]);=0A	 CloseHandle=
(hThread[1]);=0A=0AUsing the above gives us stack dump error.=0A=0APlease g=
ive us a solution as to how to implement threading.=0AEagerly waiting for y=
our reply.=0A=0ARegards,=0AHemalatha=0A=0A

Re: [Plib-users] Multithreading in FG

[Stuart M. <stu...@bl...>]

Hi,
   I can't see anything obviously wrong with that code, but here's the
solution I used.
 
I used the set of headers for threading from
 
http://www.codeproject.com/threads/thread_class.asp
 
These work on both linux and windows (and cygwin). I got them working
with no knowledge of threading
straight away and they provide a nice clean interface. They also have
mutex and semaphore classes
which are also very handy for threaded apps.
 
The code is small, easy to see what's going on and well documented. Even
if you don't use it it's
probably worth looking at to see if it helps with your problem.
 
   Good luck,
 
Stuart.
 
 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Hemalatha
Sharma
Sent: Monday, August 28, 2006 1:29 PM
To: fli...@fl...;
fli...@li...;
fli...@fl...
Cc: pli...@li...;
pli...@li...
Subject: [Plib-users] Multithreading in FG
 
  Hi,
We are using Flightgear version 0.9.4, in which we are trying to
implement multi-threading. In one thread, processing of next frame will
be done and in the other, rendering of the previous frame. Here,
fgMainLoop() is split into two threads, all the processing before
calling fgRenderFrame() in one thread, i.e. subsystem updates,
input/output updates, tile manager updates,  etc., and fgRenderFrame()
in the other thread.

Is this the correct method of splitting processing and rendering of
frame data?

We are using the below to create a thread:
hThread[1] =
CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)fgRenderFrame1,NULL,0,&dwID[
1]);
      CloseHandle(hThread[1]);

Using the above gives us stack dump error.

Please give us a solution as to how to implement threading.
Eagerly waiting for your reply.

Regards,
Hemalatha


 
<http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/s
ignature-home.htm/1507191490@Middle5?PARTNER=3> 

Re: [Plib-users] Multithreading in FG

[steve <sjb...@ai...>]

I havn't given much thought to threading alternate frames - the
reason being that the increase in latency is not worth the savings
in frame time.  I design flight simulators for a living - and the
fight to keep latency down is at least as important as the fight to
keep frame rates up.

Nothing in PLIB was ever designed for threading - so expect a LOT
of things to break!

Sadly, you are on your own on this one - this is not a path I'm
interested in treading - it's a steep and twisty path and it's
leading in the wrong direction.

Good luck!

Hemalatha Sharma wrote:
>   Hi,
> We are using Flightgear version 0.9.4, in which we are trying to 
> implement multi-threading. In one thread, processing of next frame will 
> be done and in the other, rendering of the previous frame. Here, 
> fgMainLoop() is split into two threads, all the processing before 
> calling fgRenderFrame() in one thread, i.e. subsystem updates, 
> input/output updates, tile manager updates,  etc., and fgRenderFrame() 
> in the other thread.
> 
> Is this the correct method of splitting processing and rendering of 
> frame data?
> 
> We are using the below to create a thread:
> hThread[1] = 
> CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)fgRenderFrame1,NULL,0,&dwID[1]);
>       CloseHandle(hThread[1]);
> 
> Using the above gives us stack dump error.
> 
> Please give us a solution as to how to implement threading.
> Eagerly waiting for your reply.

Re: [Plib-users] Multithreading in FG

[Stuart M. <stu...@bl...>]

Steve makes a good point. I hadn't actually looked at what you
are threading. Areas where I use threading are where I'm going
to get blocking. So reading and writing to/from the socket are
threaded. It does introduce problems, but for networked programs,
if you do it right, threads are the way to go.

BTW I've not used threads with PLIB (I only use the netSocket
class from PLIB), so I'm not sure what problems that will introduce
on top of threads themselves.

I'm not sure how you expect to get a latency drop by rendering
alternative frames in threads. I could see putting all the rendering
in a thread and all "logic" processing in another (since there won't
be input from the user to process constantly). If your code is split
right that should be doable.

I try to write as though the logic code knows nothing about the
display code. So in theory you can drop in new rendering code (say
for text only logging output) without changing anything else.

Given the amount of problems threading introduces I'd make very
sure you need the boost and that it will actually give you that
boost.


--Stuart.


-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of steve
Sent: Monday, August 28, 2006 10:42 PM
To: Hemalatha Sharma; PLIB Users
Cc: fli...@fl...;
fli...@li...;
pli...@li...;
fli...@fl...
Subject: Re: [Plib-users] Multithreading in FG

I havn't given much thought to threading alternate frames - the
reason being that the increase in latency is not worth the savings
in frame time.  I design flight simulators for a living - and the
fight to keep latency down is at least as important as the fight to
keep frame rates up.

Nothing in PLIB was ever designed for threading - so expect a LOT
of things to break!

Sadly, you are on your own on this one - this is not a path I'm
interested in treading - it's a steep and twisty path and it's
leading in the wrong direction.

Good luck!

Re: [Plib-users] Multithreading in FG

[steve <sjb...@ai...>]

Stuart McDonald wrote:

> I'm not sure how you expect to get a latency drop by rendering
> alternative frames in threads. I could see putting all the rendering
> in a thread and all "logic" processing in another (since there won't
> be input from the user to process constantly). If your code is split
> right that should be doable.

Right - physics, audio and AI in one thread - graphics in another.
(Although even doing physics in parallel hits latency unless you are
quite clever about it).