On 07/09/2013 06:41 PM, Owen Haynes wrote:
I have been using a debugger to look at pBlockedConnection and
pUnlockConnection
also added some extra print statements to the code, sqlite is also compiled
with debug enabled, and no asserts seem to get triggered.
How do you know A has finished? Does "PRAGMA lock_status"
indicate that it is holding no locks at all?
So in "deadlock 1", when you have:
Connection A is has finished
Connection B is waiting on Connection A
Connection C is waiting on Connection B
Then the following are all true?
B->pUnlockConnection = A;
B->pBlockingConnection = A;
C->pUnlockConnection = B;
C->pBlockingConnection = B;
Are both B and C in the linked list that starts at global
variable sqlite3BlockedList (and connected by pNextBlocked)?
Dan.
Owen
On 9 July 2013 11:20, Dan Kennedy <danielk1...@gmail.com> wrote:
On 07/09/2013 04:08 PM, Dan Kennedy wrote:
On 06/20/2013 03:20 PM, Owen Haynes wrote:
Hello,
I am currently having some problems with the unlock notify and getting
in a
state of deadlock.
I am using code based on
http://www.sqlite.org/unlock_**notify.html<http://www.sqlite.org/unlock_notify.html>,
with
the latest sqlite.
The setup is as follows:
- WAL is on
- Multi Threaded is on
- Temp store is memory
- Database is stored in /dev/shm
- Synchronous is set as normal
- Multi-threading is on
- connection is set as SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE |
SQLITE_OPEN_NOMUTEX | SQLITE_OPEN_SHAREDCACHE
Unlock notify does work I can see my log messages printed when the
callback
is called but sometimes I can end up in the following dead lock
situation.
Each connection is in its own thread
*Deadlock 1*
Connection A is using database
Connection B is waiting on Connection A
Connection C is waiting on Connection B
Connection A is has finished
Connection B is waiting on Connection A
Connection C is waiting on Connection B
How do you know this is what is happening? Are you looking
at the sqlite3.pBlockedConnection and sqlite3.pUnlockConnection
pointers in a debugger? Or some other method?
Also, if this is easy to reproduce, try running with SQLITE_DEBUG
defined. This will enable some complex asserts that check for
various problems in the unlock-notify code.
Dan.
*Deadlock 2*
Connection A is using database
Connection B is waiting on Connection A
Connection C is waiting on Connection A
Connection A is has finished
Connection B is waiting on Connection A
Connection C is waiting on Connection A
For some reason sometimes the notify callback does not get issued and end
up with 2 threads waiting for the callback back to be issued.
Connection B is a writer thread the others only read.
Any ideas?
Are you handling the case where the xNotify callback is invoked by
sqlite3_unlock_notify() before it returns?
Dan.
______________________________**_________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
