Martin van Beilen wrote: > Actually it is fairly easy to make the property manager Thread > Safe<tm>. 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 done.
This is the Great Myth of multithreading. Threadsafe components are not sufficient to protect against threadsafety violations. The only way to avoid deadlocks and race conditions is for the whole architecture to support them from top to bottom. Making the property manager threadsafe isn't the issue; sure it can be done. The problem is that *using* the property manager (or anything) from multiple threads leaves you open to race conditions that occur due to unsynchronized changes to the property values. For those with Java experience, consider the Vector class. It's threadsafe, right? Right. Now enumerate over it in one thread while modifying it in another. Is *that* threadsafe? :) Andy -- Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
