On Fri, 2005-07-22 at 14:00 -0700, Tim McDaniel wrote: > > History has demonstrated that programmers building > > multithreaded applications tend to produce buggier code, and > > code that touches more pages than a non-threaded version. As > > a result, the non-threaded version is easier to write, safer, > > and runs faster. > > So, what's your point? That writing things the easy way leads to safer, > less buggy, faster code? That's hardly a point. The original poster > presented one of the more compelling reasons for multi-threading in > modern apps, the GUI. It is hard, if not impossible, with modern GUI > systems to write any relatively complex app that is both performant and > graphically responsive without using threads.
I have no problems writing GTK applications without threads. I suspect the toolkits you are familiar with are inadequate. Most GUI toolkits rely heavily on callback interfaces. Closures and signal-based event notification are much more beneficial than threads: they produce fewer bugs, and are easier to program still. But this isn't an argument for closures and signal-based event notification. This is a general argument against threads. > At least for the short term, Moore's Law is slowing down, we might as > well start calling it Moore's Dream. All main CPUs are going multicore, > even game consoles, and one of the only realistic ways to take advantage > of that is through multi-threading. Saying it is hard doesn't change > reality. The other "realistic" way is multiple processes, which is the point I argue for. Threads can be useful, but they're only faster than processes if they touch less pages. Threads require more memory (synchronization primitives, etc) and many languages that encourage threading provide no mechanism to isolate those privileges onto a few pages. Those page hits tend to cause MORE page-table access than similarly-written programs than use processes. I use threads sparingly, and try to keep all memory access on the stack when I do use threads so that I am NOT touching any heap-memory (rather as little as possible), and therefore, require few synchronization primitives. I tend to not see very many programmers doing this. I suspect this is because programmers believe "threads are faster and cheaper, so everyone should use them." In general, threads don't solve problems because the problems that they CAN solve, people rarely face, and the problems that they are ATTEMPTING to solve can be solved in better, cleaner ways. > > > As another user also mentioned, a Windows system works > > better with few > > > processes with many threads. > > > > Windows uses threads because x86 page tables are expensive to > > load. It doesn't help: the system-call method Windows uses > > eats any benefit that it has, again producing net-zero. > > This being THE reason Windows emphasizes threads over processes is hard > to swallow. What? That threads are cheaper than processes? If Windows has another reason for using threads instead of processes I'd love to hear it. With all of the downsides to threads, the only reasonable one is that they _may_ be cheaper than processes. Unfortunately, that textbook _may_ is a reality _isn't_ in most cases. Nevertheless, my point to this statement was lost: Windows could optimize process creation, but it could also optimize system calls. Those steps would make the parent-threads' argument moot (not to mix metaphors). > > > I am also interested in your comments on Pointers and GoTo. I note > > > that Java is 100% pointers. Apart from basic types, all > > object access > > > is by pointer. > > > > Java uses references, not pointers. > > This is purely semantic nit picking. That's your opinion. Other languages have both. When they do, the distinction is more important. > > > Using Exceptions correctly, I have never felt the need for a GoTo. > > > Exceptions do the same as GoTo, accept, maybe, in a slightly more > > > developed and useful way. > > > > Exceptions are slower than goto. They are also less > > straightforward when deeply nested (long chains of throws XYZ > > come to mind...) > > > > I would agree that exceptions are not a good replacement for gotos. > However, having been a professional C++ programmer for over 10 years, I > have never needed a goto. This probably stems more from the fact that > with C++/Java/C# you don't really need gotos, but with C/Basic/etc there > are arguably things that you can't do, or would be quite hard to do, > without gotos. I'm glad I gave you an opportunity to post your VC. Meanwhile, while C doesn't _need_ gotos: for (i = 0; i < n; i++) for (j = 0;j < m; j++) if (q(i,j)) goto TAIL; TAIL: looks better than the alternative. Just because you don't _need_ a condom doesn't mean it's not a good idea. I think that avoiding goto is good for the same reason that avoiding threads are good. Once you've gotten used to knowing why they're bad is when you can begin to safely start using them for the right thing. Maybe in another 10 years you'll be ready to start using the right tool for the job. Maybe sooner. > > > These are just my opinions :) > > > > They are wrong. > > > > I hope there was a hint of sarcasm in that last comment. The original > poster obviously didn't hit everything on the nail, but there is a whole > world of gray between right and wrong. Not sarcasm. Sardonicism. Computer _Science_ is just that: Science. It's not opinion.
