Andy Ross wrote:
safety lock; even a perfectly threadsafe property system is
susceptible to race conditions.
The point, again: *all* multithreaded code is susceptible to race
conditions and deadlocks. There is *no* way around this. The only
way to avoid them is to be very, very careful
I like the consept of multiple programs (communicating through sockets
or pipes) over threading anyhow, and that *forces* you to think about
it :-)
You are right about the example you gave, the pth packages only
removes the multiple r/w operations on the same value at the same
time (which might
=http://www.iradis.org/
PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B
From: Martin van Beilen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment
In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Mon, Feb 25, 2002
Martin van Beilen writes:
Working from a single thread is obviously the easiest solution,
where possible. However, in the case of our property system,
potentially any part of the code may want to access those
properties. We'd have to assign one thread as the property
manager, and do
Curtis L. Olson writes:
Threading is *really* scarey in a program of this magnitude. Even
the current threaded tile manager is a big time bomb waiting to
happen. We are getting away with doing stuff that's not guaranteed
to work. We've taken a lot of steps to try to minimize the
Curtis L. Olson writes:
Textures: any threading that involves portions of opengl needs to be
handled very delicately.
No, I wouldn't touch OpenGL. I'm talking about generating textures
in-memory; they would then be passed off to the main thread for use by
OpenGL. We're a long way from
David Megginson writes:
Anyway, in the back of my head, someday, I want to try to develop a
case against the threaded tile pager and maybe figure out a way to to
partial per frame model loading and unloading ... not that I don't
desparately wish we could do it, it's just that I'm not
Curtis L. Olson writes:
David Megginson writes:
What you need to do is isolate the tile manager completely, so that it
has (almost) no dependencies on the rest of the program, except for
one structure for data exchange.
I don't think the solution can be that trivially simple. The
D Luff writes:
Surely it is possible to do a byte by byte copy of the tile from disk
to memory in a separate thread, without *any* Opengl/ssg/plib
dependency, such that the main thread need only access memory
and not disk?
Surely it is possible, but if your goal is to push all time
Curtis L. Olson writes:
D Luff writes:
Surely it is possible to do a byte by byte copy of the tile from disk
to memory in a separate thread, without *any* Opengl/ssg/plib
dependency, such that the main thread need only access memory
and not disk?
Surely it is possible, but if your
D Luff writes:
Fair enough. I was under the impression that it was the disk
access taking the time.
Registering new textures with opengl can take a noticable amount of
time (especially when they are large.) Freeing memory (and any
associated garbage collection) can actually be a *big* hit
Curtis L. Olson wrote:
D Luff writes:
Fair enough. I was under the impression that it was the disk
access taking the time.
Registering new textures with opengl can take a noticable amount of
time (especially when they are large.) Freeing memory (and any
associated garbage
Martin van Beilen wrote:
Actually it is fairly easy to make the property manager Thread
Safetm. All regular r/w locking can happen on a per-node basis, and
can be encapsulated transparently. The property manager seems like an
ideal candidate for IPC messaging, so if we want, it can be
Andy Ross wrote:
Curtis L. Olson wrote:
Threading is *really* scarey in a program of this magnitude.
I'd be adverse to adding additional threading especially if it
involves something like the property manager.
There might be specific isolated instances where we can do it
Erik Hofman wrote:
This would remove the need for locking (expept for OpenGL I gueass).
guess, guess, guess.
(I'm improving).
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
D119 4FE0 AE3A 37CF 3458 FE87 448B
From: Martin van Beilen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment
In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Mon, Feb 25,
2002 at 12:55:07PM -0800
X-S-Issue: [EMAIL PROTECTED] 2002/02/26 00
Martin van Beilen wrote:
Andy Ross wrote:
For those with Java experience, consider the Vector class. It's
threadsafe, right?
No, it's not. Imagine what happens when one thread is reading it
while another thread is writing to it. :-)
Right. Now enumerate over it in one thread
PROTECTED]
Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment
In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on
Sat, Feb 23, 2002 at 08:47:17PM -0500
X-S-Issue: [EMAIL PROTECTED] 2002/02/25 01:16:48
a8e24c3bfcb47364f995b5835fa3f007
-BEGIN PGP SIGNATURE-
Version
3458 FE87 448B
From: Martin van Beilen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment
In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on
Fri, Feb 22, 2002 at 05:46:11PM -0500
X-S-Issue: [EMAIL PROTECTED] 2002/02/23 20:48:54
Martin van Beilen writes:
Removal is a bit of a problem though. In the current situation
properties are created for life. We could just leave unused
nodes, or I could add a delChild() method, or I could add it to
the destructor. What do you think?
Properties exist for life because any
, I RADIS, do you?
=Martin=http://www.iradis.org/
PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B
From: Martin van Beilen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment
In-Reply-To: [EMAIL PROTECTED]; from [EMAIL
Martin van Beilen writes:
Well, that's the easy part. We can add a DELETE flag and set it
on all dynamic properties. I'm more worried about multithreading.
It may be necessary to implement a locking scheme to prevent
simultaneous access and deletion of a property. (Only if DELETE
is
[EMAIL PROTECTED] writes:
When you say weather/environment management system what do you mean?
Do you mean something that includes the following?
1. weather data retrieval mechanism
Yes. I'm starting with the front-end (the interface between
FlightGear and the rest of the environment
On Fri, 22 Feb 2002, David Megginson wrote:
2. conversion from raw form to a source independent format stored
either in memory, or a persistent format
Yes, if you mean METAR parsing and the like.
Yes, that's what I meant.
I'll probably isolate that behind a generic interface, so that
[EMAIL PROTECTED] writes:
Is it safe to assume that if one wanted to add support for winds
aloft reports, they would only need to add code to acquire the data
and then parse it into some kind of data structure defined by your
system?
That's to be determined.
How much support will
=http://www.iradis.org/
PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B
From: Martin van Beilen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment
In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED]
on Thu, Feb 21, 2002 at 07
That's also to be determined. As I mentioned, I'm working from front
to back. FGEnvironment contains a set of environment information for
a single place and time. Once we get that working better, I'll add
FGEnvironmentManager to get the environment information for places
(and times?)
On Thu, 21 Feb 2002, Curtis L. Olson wrote:
Just like we have competing FDM's with different focus, strengths
and weaknesses, I don't think it is bad to have competing
weather/environment management systems with different focus,
strengths and weaknesses.
When you say weather/environment
28 matches
Mail list logo
