Op 9 jan 2014, om 19:50 heeft Ward Willats het volgende geschreven:
BUT, I was wondering if there are scenarios where only two threads
can bounce each other into busy sleep like two bocci balls colliding?
(one thread wanted a read lock, the other a BEGIN EXCLUSIVE write lock)
On Jan 9, 2014, at 10:10 AM, Roger Binns <rog...@rogerbinns.com>
wrote:
The default busy handler (see sqliteDefaultBusyCallback in source)
sleeps
for these amount of milliseconds:
{ 1, 2, 5, 10, 15, 20, 25, 25, 25, 50, 50, 100 };
However on non-Windows if you do not have HAVE_USLEEP defined then it
sleeps with a granularity of one second. The blocking thread could
have
finished after 10ms, but you'll still be stuck in the busy handlers
for
another 990ms.
Simply ensure HAVE_USLEEP is defined when building sqlite3.c. Or
add your
own busy handler that sleeps for sub-second amounts of time.
I was more interested in the scenario than the solution -- but I
probably would have missed this simple fix and done something
elaborate and stupid, so thank you very much!
-- Ward
Indeed there is a scenario where two threads block each other. I think
this occurs when more than one thread acquires a RESERVED lock. SQLite
detects deadlock in such case and does not invoke the busy handler. So
with two threads you can see at most one waiter. If you have two
waiters the conclusion is clear ..
_______________________________________________
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
