At 2006-11-15T11:52:22+1300, Derek Smithies wrote: > On Wed, 15 Nov 2006, Carl Cerecke wrote: > > Threads make programs hard for programmers to reason about.
Ultimately this is true of any asynchronicity in a program, not just that caused/provided by threads. > When your program is handling multiple disparate real world events > (multiple sockets, timers etc) as it communicates with external programs > on a different computer, things like determinism disappears. Long > disappears. True, but there is a big difference in the difficulty of reasoning about program behaviour between a single-threaded program dispatching around a call to select() (or some other event dispatching mechanism) and an arbitrarily threaded program. > Now, when you get computers with multiple cores, and we are seeing more > computers with mutliple cores, wouldn't it be nice to write code to take > advantage of the cores? Sun have computers with tens of cores. My current > desktop has two cores. > > With threads, I can easily take advantage of all the cores the computer > will give me. You can do that with processes, too. The major difference between threads and processes is that threads default to shared-everything, and processes default to shared-nothing. Unfortunately, it's almost impossible to start with threads and move towards a shared-nothing design, because you've given up all of the protection processes give you, and you can't add a lot of that that back without special hardware support. > Interestingly, Sun have a system called openmp, which handles threads > nicely - the compiler actually works out the parrallelism. The writer > gives some guidelines, and the compiler does the rest.. OpenMP is really only useful for making trivially parallelizable code run in parallel. Most problems are not trivially parallelizable. There's nothing magic about OpenMP. Also see Tridge on threads: http://lists.samba.org/archive/samba-technical/2004-December/038301.html Cheers, -mjg -- Matthew Gregan |/ /| [EMAIL PROTECTED]
