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.
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 :)
As another user also mentioned, a Windows system works better with few
processes with many threads.
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.
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.
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.
These are just my opinions :)
Regards,
Ben Clewett.
D. Richard Hipp wrote:
On Fri, 2005-07-15 at 16:41 +0530, Roushan Ali wrote:
Hello all,
Can we use single sqlite_open handle(global) across threads(
if all database operations are serialized by using semaphore) ? Please
help.
Opening a database connection in one thread and using it in another
will work on some operating systems but not on others. You are
advised not to do it. See http://www.sqlite.org/cvstrac/tktview?tn=1272
and http://www.sqlite.org/cvstrac/chngview?cn=2521.
Actually, this seems like a good opportunity to repeat my
oft-ignored advice to not use more than one thread in a single
address space. If you need multiple threads, create multiple
processes. This has nothing to do with SQLite = it is just
good programming advice. I have worked on countless multi-
threaded programs over the years, and I have yet to see a
single one that didn't contain subtle, hard to reproduce,
and very hard to troubleshoot bugs related to threading issues.
I am constantly amazed at the prevailing idea (exemplified
by Java) that software should be strongly typed and should
not use goto statement or pointers - all in the name of
reducing bugs - but that it is OK to use multiple threads
within the same address space. Strong typing helps prevent
only bugs that are trivially easy to locate and fix. The
use of goto statements and pointers likewise results in
deterministic problems that are easy to test for and
relatively easy to track down and correct. But threading
bugs tend to manifest themselves as timing-dependent
glitches and lock-ups that are hardware and platform
dependent, that never happen the same way twice, and that
only appear for customers after deployment and never in a
testing environment.
