Hi Ben, You're right about the native vs pseudo threads-own schedule issue and in fact this is exactly how most Java Virtual Machines handle it.
The JVM's that support native threads contain a runtime time switch that allows you to turn it on and off - this means that your application can be built without knowledge of whether the threading is controlled by the OS or by the JVMs own scheduler. Here's a nice comparison of the two types:- http://www.mit.edu/afs/athena.mit.edu/software/java_v1.1.6/www/native_thread s.html I think I'm right is saying that most multi-user database kernels will have started out life as being natively single threaded (except the asynch I/O), but containing their own pseudo thread scheduler. That's certainly still the case with the database I most heavily use, Livelink for Collections Server. Steve -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] rg]On Behalf Of Ben Clewett Sent: 25 July 2005 13:35 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Multi-threading. Steve O'Hara wrote: > I think the point about multi-threaded apps is not that there might be a few > instances where they are useful, but how easy is it to debug and support > them and is it worth the price for a little more concurrency? Good point. The ones I have used are terrible. I hope things will improve in time. This is hopefully not a reason to give up. > In my experience, most debugging IDE's can't handle multiple threads and > actually turn the application into a pseudo threaded version prior to > running it. I wouldn't mind betting that's what's going on in Java (it's > worth pointing out that Java didn't used to even support native threads and > I bet most Java programmers have no idea whether they are actually using > Native or pseudo threads) > > Because of this, you get the frustrating situation where an application > works fine in debug but fails sporadically in production. Another good real > world example of this is the IIS/ASP server side debugging. IIS allocates a > new thread per request which are autonomous but do some semaphoring to share > the Session object (I think). There's a handy switch you can set on your > IIS virtual directory that turns on server side debugging - great! ..... > only, not so great!! Suddenly IIS starts allocating the same thread to every > request i.e. it queues your requests and the very problem you were trying to > solve goes away! :) > The moral of the story is as Richard says, if there isn't a burning need for > multiple threads then don't use them. I have noticed something. There are two lines of thought here. The two ideas may not be too different. (Here is where I am sure I will be flamed, but I am sure I'll learn something from it :) - The single-thread multi-task option. - The multiple-thread single thread-task. The first option involves building a context scheduler into our own programs. So GUI events, TCP listen, and everything else can occur without blocking. A virtual thread environment. As you say, some Java and ISS can sometimes be this. The second option involves letting the OS do the context changes. Letting the programmer just code each thread in isolation. (Programming in a thread-safe way.) So in essence, the two become the same. A switch could even be added to use own context switch, or use the OS. The OS could be virtual or physical. Externally it's not important: any option should yields the same function. Therefore, programming ones own context scheduler is a bit like not using SQL and accessing the data file directly. It may be faster, you may have more control. But you may just be giving your self a lot of work where SQL does it all for you. This is why we all like SQLite so much. I do not know if this is the case today. My assumption is that thread safe programming is easy, by using good tools and good methodology. I truly believe this, and I have not experienced some of the thread problems other people have reported. Considering the future of processor design, should we be getting more excited about threads and how we can make them work for us? > By the way, Mrs Brisby is being facetious when he says that he doesn't > regard Windows as a "modern" GUI - there's no such thing! They've all got > their origins in concepts put forward over 20 years ago. :) Ben. > > Steve > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > rg]On Behalf Of Ben Clewett > Sent: 25 July 2005 09:01 > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Multi-threading. > > > 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. >> > > > > > >
