On Tue, 26 Feb 2002 10:53:11 +0100, Erik Hofman <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>:
> 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. ..say I build my self a plane the EAA (eea.org) way, in 4 years. And that I want to use a class cockpit and build upon FlightGear code. ..which of the above concepts is easier to make airworthy, and to certify as airworthy? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
