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!