On Wed, 2005-07-20 at 17:26 +0100, Ben Clewett wrote: > Dr Hipp, > > I am just playing devils advocate here because I have completed much > Java programming in a multi-threaded application. :) > > I understand the problems of multi-threading. I am reminded that it > took nearly 20 years of development to get multi-processor support in a > modern OS stable. Much success for this can be attributed to Semaphore > Flags. With CPU hardware support to ensure that the semaphore it's self > cannot be controlled by more than one process.
ITC in 1970 supported multiple threads trivially. > Multi-thread applications suffer the same problems. Without semaphore > flags or 20 years of development. A novice programmer can happily > create a second thread and quickly create terribly applications. .... > However the need for multi-threads is compelling. Especially in a GUI > environment. For instance a Mail reader. Where one thread is needed to > ensure the GUI is drawn correctly and respond to GUI events. Another to > download and dispatch mail. (My Thunderbird has 10 threads. This may > be a bit of overkill :) No. Threads are not a need. They allow you to use blocking system calls in parallel without extra page table loads. 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. > 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. > I believe the issue is not whether to use threads, but to use them > correctly. Which is not a hard thing to do with a little support. .... > This is where Java (and .NET) work well. If you use them correctly. > They provide thread-safe objects. Which have been designed to use > semaphore flags internally. If the programmer uses these thread-safe > objects correctly, they will not encounter thread issues. For instance, > all communication between threads should be exclusively through these > thread-safe objects. Java uses threads poorly. They're expensive to set up, and many Java programmers yield to non-blocking methods as Java closures tend to be easier to program, and faster too. > Further, Java and .NET provide Sycronisation methods. The defining of a > method to be synchronised automatically creates the locks to ensure > thread safe access. ... > 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. > 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...) > These are just my opinions :) They are wrong.
