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 with your design. You > cannot rely on libraries to save you. You cannot rely on simple > techniques to save you. You have only your mind, your experience, and > the minds and experience of the yahoo threading cowboys working on the > rest of the project to rely on. Now, are you getting the point? :)
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 be a good step foreward anyhow), but indeed it doesn't save you from *all* problems. Erik _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel