I find it much simpler to put a mutex around the accesses (or make them
a critical section). That serializes the access and avoids busy waits,
retries etc. It will prevent a certain amount of read concurrency. but
that may be insignificant.
If you use pthreads and have plenty of reads for each write you might
use pthread read/write locks instead of plain mutexes. You can
synthesize read/write locks from windows locking calls if you are patient.
Andreas Volz wrote:
Am Wed, 9 Jan 2008 10:20:31 -0800 (PST) schrieb Ken:
Definately use 3.5.4.
Not sure how to determine at compile time if the threadsafe part is
enabled. You can always compile yourself to guarantee its set, thats
what I do.
sqlite will lock the database file for you automatically. Your
threads do not need to implement locking. But they do need to handle
in some fashion. SQLITE_BUSY and/or SQLITE_LOCKED error codes.
You should also look at "Begin", "Begin Exlusive" and "Begin
Immediate" sql commands.
Ok, I found the docs. But I exec only single SQL queries at the moment.
So I think I don't need that.
As a user you don't get to pick the lock state, sqlite does that
automatically for you. You must handle the return codes suche as
SQLITE_BUSY, SQLITE_LOCKED etc.
Now I implemented a multi-threading example that reads and writes in a
database file. Currently I check return values and if in BUSY or LOCKED
state I wait some time and try it again until I get the lock.
It works, but currently I have around 20 BUSY operations for 5
successful write operations in 5 threads parallel threads.
Is it really the way of choose to do it this way? Isn't there a way
without active waiting? I would prefer exec() blocking until I get a
write lock to not have to loop with a sleep until it works.
regards
Andreas
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
