Erik Hofman wrote: > Andy Ross wrote: > > Amen. The only purpose to doing threading in a C/C++ environment is > > SMP scalability (in Java, you have to use them for I/O multiplexing > > too; I consider this a bug, but at least there you have language > > Well, the main reason for using multi-threading in a single CPU > environment is to use the CPU cycles when a program (or thread) is in > an IO lock ...
No. That's what I meant by "I/O multiplexing" in the java note, and I hold to my statement: using threads for this is a bug. The right way to do this is to use non-blocking or multi-blocking I/O calls (select() being the poster child, but Win32 has non-blocking calls too) that allow you to sanely and safely use the CPU at all times without fear of race conditions. > BTW. There are thread schedulers which work in a single address space, > pth is one example: > > http://www.gnu.org/software/pth/ > > This would remove the need for locking (expept for OpenGL I gueass). Ack, no, it wouldn't. It would remove the need for locking against preemptive scheduling that might schedule another thread. This is *not* the only kind of race condition! For a specific example, you're liable to the following bug: if(!fgGetBool("/controls/trigger-safety-lock")) { SG_LOG("Bombs away!"); dropNuclearArmament(); } The race condition? The logging statement does I/O, and thus allows the scheduler to pick another thread which might toggle the value of the property. The safety lock thus isn't guaranteed to be off when the bombs drop. Now, you can fix this via explicit locking ("/controls/trigger-safety-lock-lock", heh), or implicit design (only one thread sets the /controls tree). But simply saying expecting the userspace thread library to keep you out of trouble isn't going to work. You need to design threadsafety in from the beginning; no options. All of this is just a long-winded way of making Curt's point: threading is a *hard* problem, and there's simply no way to make it easy. There are no magic bullets here -- you can't use a single library, or tool, or technique, and be able to say "my code is threadsafe". Threads are dangerous. Stay away whenever possible (this means: stay away unless you need more than one thread for a fundamental reason, like SMP scalability). 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
