Re: [sqlite] Saw something interesting in the debugger...

[E.Pasma]

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   
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

Re: [sqlite] Saw something interesting in the debugger...

[Ward Willats]

On Jan 9, 2014, at 10:10 AM, Roger Binns  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

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Saw something interesting in the debugger...

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/01/14 08:53, Ward Willats wrote:
> I found the UI thread and a worker thread, both in the DB, both in the
> default busy handler, both taking a 1 second sleep.
> 
> I expected to see a third thread in the DB doing some work while the
> other two waited -- but no such thing.

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.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iEYEARECAAYFAlLO5gYACgkQmOOfHg372QQffACferRzozDtbmZqn+R/fVwxMKtf
rkYAn0oQDoHSne95rciPUlfqPCeN3yCv
=fAg3
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Saw something interesting in the debugger...

[Ward Willats]

I've got a multi-threaded iOS app. Each thread has its own long-lived DB 
connection.

I was debugging a "stuttering" in the UI thread and broke into the debugger 
during one of the pauses.

I found the UI thread and a worker thread, both in the DB, both in the default 
busy handler, both taking a 1 second sleep.

I expected to see a third thread in the DB doing some work while the other two 
waited -- but no such thing.

Now, I could have missed it. A third thread could have gotten in and out by the 
time I broke in.

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)

-- Ward

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users