On Friday 19 March 2004 08:26 pm, Andy Sy wrote: > Andy Sy wrote: > > There's a flipside to this 'convenience' though, you have > > to be very mindful of how your threads access your shared > > variables. Deadlock bugs pop up in a nondeterministic manner > > and are notoriously hard to pinpoint.
the way i see it, threads are convenient in the same way global variables are convenient. and the problems they bring (threads, and global variables) are similar, or at least related. now, i *like* threads (in java, anyway, synchronized is very nice even though it *is* syntactic sugar and can be simulated by semaphores and similar constructs. haven't worked with POSIX or C/C++ threads). but the deadlock issues are similar to corruption of global data (in programs that have globals) in the sense that it's necessary to dedicate effort and discipline to using the globals (or the multiplied "globals" in threads) in a responsible way. it's possible to write reliable software even with global variables, it's just *harder*. it's necessary to be very disciplined. threads extend the concept of "global" and "modified or viewed in multiple ways, in dangerous sequences of events" even to private or protected (at any rate, to non-public/global) data which are passed by reference to functions which then pass these data to other functions which create threads and use the variables in those threads. it's possible to write efficient and reliable software using threads. and in fact, as i say, i *like* threads in java (and i'd probably like them in the Posix libs too, if i had the courage to use them in C/C++), but the discipline is a major requirement. as noted above, if anything, it's even more important than in single threaded programs that use global variables. because it is now possible for multiple threads to touch "global" (even just coincidentally global data, e.g., objects passed by reference to more than one thread such that their state is being changed in virtual timeslice time by multiple threads) "at the same time" [close enough to realtime]). when a program is multithreaded, *any* variable that is passed by reference to any function is potentially a "global" variable. and if any variable is passed by reference it becomes incredibly difficult (sometimes, even impossible) to determine if the use of that variable is safe. since the program is no longer single threaded, it is possible for the variable to be touched (accessed/modified) in dangerous way in almost non-deterministic ways (because of the simultaneity of the access). multi-threaded access in undisciplined ways is certainly polynomially and is probably exponentially more difficult to predict and analyze than global memory access in single threaded programs, even if the single threaded code is spaghetti. now, again, i'm not entirely against threads. they're very nice when used in a disciplined way. in java, the only thing i don't like about threads is the fact that the overhead (stack requirements) is so high (although that can be adjusted, at a cost to thread stability, since highly recursive threads *can* hit their bottom and die nasty deaths) that it's not really a reasonable use of threads to create 1000 threads (for programs that need to keep thousands of client sessions alive at the same time, i still prefer select to the old (now superseded because it's proven impracticable) java model of creating a new thread for each client connecting to a socket server). but again, i'm a pragmatist. use threads when they make sense. avoid them where they don't. as always, understand the pros, cons, and tradeoffs and make rational decisions based on all the factors that you can make fit in your head :). i tend to simplify my analysis and use lots of approximations since my pointy head just doesn't hold as much information as it used to :). tiger -- Gerald Timothy Quimpo gquimpo*hotmail.com tiger*sni*ph http://bopolissimus.sni.ph Public Key: "gpg --keyserver pgp.mit.edu --recv-keys 672F4C78" Veritas liberabit vos. -- Philippine Linux Users' Group (PLUG) Mailing List [EMAIL PROTECTED] (#PLUG @ irc.free.net.ph) Official Website: http://plug.linux.org.ph Searchable Archives: http://marc.free.net.ph . To leave, go to http://lists.q-linux.com/mailman/listinfo/plug . Are you a Linux newbie? To join the newbie list, go to http://lists.q-linux.com/mailman/listinfo/ph-linux-newbie
