Unless you have a multi processor machine or some form of parallel
processing I cannot see how you can do anything other than slow your
procesing by adding threading overhead.
You can simplify the conception of the whole process by understanding
that Sqlite writes to a single file on a single file system on a single
disk drive.
If you had a database striped across multiple spindles and with multiple
processors you would gain by parallel processing, but I very much doubt
whether you have such an environment.
My suggestion is that you queue your activity to maximize throughput and
use transactions or a more radical speedup. Your application looks as
if you are creating some form of index which means that you can run
Sqlite in its fastest and least safe mode because a crash can be
repaired simply by restarting your job.
Emerson Clarke wrote:
Im not sure that the current situation of forced thread
incompatibility is better than leaving it up to users to manage the
threading. Usually it is assumed that a library is thread unsafe
unless otherwise specified.
Developing multithreaded applications is difficult, i wouldnt dispute
that. But i do dispute the wisdom of actively making a library
incompatible with threads. Sqlite is the first example of such
behaviour i have seen, it deliberately fails even if the user attempts
to synchronise concurrent access.
Surely it would be better to design the api so that it was either
fully thread safe and blocked on every call to an sqlite_ function
using its own mutexes, or to simply ensure that it was process safe
using shared memory. As i mentioned in a previous reply,
synchronising sqlite would be no more or less difficult or error prone
than synchonising a linked list.
I dont see what is gained by making it not work with threads, so i
assume that it is becuase of some technical reason rather than a
design decision.
Anyway, as another user has pointed out. You can compile the library
in such a way as to allow the thread synchronisation routines to be
overridden so i think i have a solution to the problem, but perhaps
not an answer as to why things are the way they are.
On 12/29/06, Jay Sprenkle <[EMAIL PROTECTED]> wrote:
On 12/27/06, Emerson Clarke <[EMAIL PROTECTED]> wrote:
> The first question is why database locking has been enabled on a per
thread
> basis instead of per process so that the normal methods of thread
> synchronisation (mutexes, ciritcal sections) could not be used for
> maintaining consistency within the application. The programmer can
easily
> ensure that no two statements are executed at the same time just as
they
> would ensure that no more than one operation on a linked list was
performed
> at the same time.
Having watched a lot of people attempt to write thread safe code I would
say this is an incorrect assumption. I think it only appears simple at
a casual
glance.
--
The PixAddixImage Collector suite:
http://groups-beta.google.com/group/pixaddix
SqliteImporter and SqliteReplicator: Command line utilities for Sqlite
http://www.reddawn.net/~jsprenkl/Sqlite
Cthulhu Bucks!
http://www.cthulhubucks.com
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
