----- Original Message ----- From: "Ben Clewett" <[EMAIL PROTECTED]> To: <sqlite-users@sqlite.org> Sent: Wednesday, July 20, 2005 12:26 PM Subject: Re: [sqlite] Multi-threading.
> 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. whatcha talkin bout willis? all you need to fence access to a shared resource is a set of atomic operations which carry the semantics you are looking for. this has been around for quite some time. > Multi-thread applications suffer the same problems. Without semaphore > flags or 20 years of development. say what? > A novice programmer can happily > create a second thread and quickly create terribly applications. yes. non-novices too, hence richard's advice. > As another user also mentioned, a Windows system works better with few > processes with many threads. this has to do with process creation being a very expensive operation in windows. just because a certain platform cripples something doesn't make it bad. > 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. you've got no idea. there are *very* few threading interfaces which make writing correct code reasonably easy. java and .net are certainly not among them. erlang is, but the trouble is they're implemented as microthreads, so you're still stuck with problems making blocking syscalls. > 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. stop misusing 'semaphore' already, semaphore is not a synonym for a synchronization object - it is a kind of a synchronization object and has a very narrow definition. > Further, Java and .NET provide Sycronisation methods. The defining of a > method to be synchronised automatically creates the locks to ensure > thread safe access. you don't get the point. this (as opposed to more intuitive primitives *around* threading, such as actors) is just a couple lines of code here and there in a language which does not have syntax for it. coders have to understand the issues and use the locking primitives they are given correctly. i'd say your opinions, as expressed in your message, demonstrate that the mere presence of higher level sycnhronization primitives in a development platform does not magically make users of said platform understand threading issues. > 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. this is why teaching java in cs 101 is a bad idea, people have no understanding of how things work 'under the hood' anymore. java uses references, which are implemented as primitives in the jvm itself. > 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. then you haven't coded anything complex enough to require them. i can tell you that they are an absolute necessity when dealing with a lot of nesting, which may or may not deal with error handling. dijkstra was preaching against using goto to create spaghetti code; many experienced coders use gotos to *improve* readability and hence maintainability of their code. 'using'-like constructs give you *some* of this, but you will still want gotos even in languages where both exceptions and using are available when dealing with non-trivial logic. > These are just my opinions :) no offense, but you probably want to have the correct data from which to derive your opinions ;) -p
