I have a multithreaded (2 threads) application that does a large number of
tiny updates (each update is a seperate transaction). After running for
awhile the application ends up getting stuck with both threads unable to
acquire a lock on the database.
I am running version 3.2.1 of sqlite and I have applied the patch to fix a
previously reporting multithreading problem (to do with the global
recover). I am running this on a Redhat 9 machine with dual Xeon
processors. On this system, I have:
threadsOverrideEachOthersLocks = 0
Working through some debugging traces (with the addition of some printfs
for each of the fcntl operations), I see the following sequence which looks
like there is a slight problem in the locking logic for systems in which
the thread locks do not override each other. I get the following sequence
of locking operations:
Initially the lock is unlocked.
Thread #1: aquire SHARED lock [sets read lock on SHARED bytes with fd 1]
Thread #2: want SHARED lock, granted it because someone in my process has a
SHARED lock already
Thread #1: unlock lock [no locking performed]
Thread #2: want RESERVED lock [sets write lock on RESERVED byte]
Thread #2: want EXCLUSIVE lock
[sets WRITE lock on the PENDING byte]
[fails to set write lock on SHARED bytes with fd 2]
That is, one thread acquires a shared lock, another thread piggy backs on
this shared lock and then eventually the second thread (which did not
itself do the file locking for the shared lock) tries to change the lock
which is not valid.
I unfortunately don't have a simple program that illustrates the problem,
but I would be happy to apply any patches that someone can offer (or test
versions from the cvs if that is easier).
Cheers,
Chris.
--
Christopher R. Palmer [EMAIL PROTECTED]
Vivisimo, Inc. www.vivisimo.com
