Dear Mrs Brisby,Thanks for your passionate replies to my original posting. You have much information here. It's obvious I don't know everything about threading.
I like what you say about computer science being a Science. This is exactly my point. A science is a collection of theories which hold true within a domain until otherwise dissproven. For instance Isac Newtons's law of gravety and Einstain's law. Both are true within a fixed domain. Both are used today. Neither are truelly corrrect. There will be another more complex theroy in time.
This is the same with Threading. There may be places where this is useful. There may be places where it should not be used. Both are theories within computer science which hold true in a limited domain. So when I said this was my opinion, I should have stated this is my theory within a fixed domain. However when you stated that I was wrong, I don't think this is compatible of your statement that Computer Science is a Science. Nothing in any science is either right or wrong. That's a Religion.
I don't want to spend ages on the argument, I can see there are passionate views. I only want to explore the idea that threading is a viable strategy for a modern high level language and can produce stable applications with low development time.
For instance a call to a TCP blocking Wait. It's perfectly possible for one thread to cycle round handing GUI events, then checking on the port for new packets.
But an alternate method is to partition the code space into two autonomous threads using their own variable set. Two simple sets of code which are not coupled, and remain highly cohesive and encapsulated. Communicating through a thread-safe object. Such code is fast to write, easy to read, robust and does the job. I can complete this in c# in ten minutes, and it will not break. With large amounts of time, better methods may be available. But this theory is viable within its domain.
> I wasn't about to consider Windows a modern GUI system :)Are you saying it's not modern, or not a GUI? It may not be prefect and it is very complex. But it's not about to go away, and it's installed on modern computers. More importantly, my views on threads remain. If you give the GUI it's own thread, you have implemented a simple solution to ensure that the correct cursor and mouse events are honoured. Then a worker thread is free to do what ever it likes without being coupled to the GUI. Simple robust coding using thread-safe objects.
I am also interested in peoples views that threading is slower. Since all processors are likely to be hyperthreaded, multicore, or both. I can see no place where this will be true in the future.
> Java uses references, not pointers.Is there any important difference? My point was not about language. It was a question to Dr Hipp about what he feels is missing from the Java pointer (reference) model. Perhaps I should have explained better.
Yes, I understand that 'c' can make use of goto, and that goto is fast. There are also very very bad places to use goto. Exceptions, breaks and continue statements are linear code, easy to follow and more robust to code changes. Goto is a legacy of assembler programming. I don't think it's time to teach new coders about goto. Which is my theory within a fixed domain.
Regards, Ben. Mrs. Brisby wrote:
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.
