I was talking about using sleeps. I show 1ms minimum on my system.
This code executes in 1 second so that makes the minimum sleep 1ms on my Linux
system.
#include <time.h>
struct timespec req;
int
main ()
{
int i;
for (i = 0; i < 1000; i++)
{
req.tv_nsec = 1;
nanosleep (&req, NULL);
}
return 0;
}
Michael D. Black
Senior Scientist
Northrop Grumman Mission Systems
________________________________
From: sqlite-users-boun...@sqlite.org on behalf of Pavel Ivanov
Sent: Tue 5/18/2010 12:55 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] read only databases and in-memory databases
> I was still talking about sleeping for spinning the BUSY return -- but just
> doing it as fast as possible without using much CPU instead of picking 10ms
> which seeem too long to me when the transactions should take sub-millisecond
> times.
What do you mean by this? I don't understand you. Could you give a
code example? How do you want to "spin as fast as possible" without
sleeps and without using CPU?
Instead of picking 10ms you could of course pick 1ms or 1ns but then
OS will pick minimum sleep interval for you (on Linux it's about 10ms
IIRC).
Pavel
On Tue, May 18, 2010 at 1:50 PM, Black, Michael (IS)
<michael.bla...@ngc.com> wrote:
> Rats on the interprocess locks.
>
> I was still talking about sleeping for spinning the BUSY return -- but just
> doing it as fast as possible without using much CPU instead of picking 10ms
> which seeem too long to me when the transactions should take sub-millisecond
> times.
>
>
> Michael D. Black
> Senior Scientist
> Northrop Grumman Mission Systems
>
>
> ________________________________
>
> From: sqlite-users-boun...@sqlite.org on behalf of Pavel Ivanov
> Sent: Tue 5/18/2010 12:37 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] read only databases and in-memory databases
>
>
>
>> Actually I wonder if the sqlite3 mutex calls would be better yet.
>> http://www.sqlite.org/c3ref/mutex_alloc.html
>
> They work only inside one process. They won't provide inter-process locks.
>
>> If they do what I think they would guarantee FIFO and fastest possible
>> response to the users.
>
> I don't know how pthread mutexes are implemented but generally
> speaking mutexes don't have to guarantee FIFO and fairness in any way.
> Although most implementers of course try to make some sort of
> fairness, but only "some sort of" and no strict FIFO.
>
>> As long as you're not burning a lot of CPU why not spin the BUSY as fast as
>> possible?
>
> Spinning without sleeping *always* burn *a lot* of CPU, no matter what
> you do inside your cycle.
>
>
> Pavel
>
> On Tue, May 18, 2010 at 1:24 PM, Black, Michael (IS)
> <michael.bla...@ngc.com> wrote:
>> Actually I wonder if the sqlite3 mutex calls would be better yet. They
>> would appear to guarantee synchronization and you could just allow them to
>> block when BUSY or use the try function if you want to timeout.
>> http://www.sqlite.org/c3ref/mutex_alloc.html
>>
>> If they do what I think they would guarantee FIFO and fastest possible
>> response to the users. This means they would also guarantee minimum
>> resource usage as you'll be getting rid of processes faster when contention
>> occurs.
>>
>> As long as you're not burning a lot of CPU why not spin the BUSY as fast as
>> possible?
>>
>> Michael D. Black
>> Senior Scientist
>> Northrop Grumman Mission Systems
>>
>>
>> ________________________________
>>
>> From: sqlite-users-boun...@sqlite.org on behalf of Simon Slavin
>> Sent: Tue 5/18/2010 11:49 AM
>> To: General Discussion of SQLite Database
>> Subject: Re: [sqlite] read only databases and in-memory databases
>>
>>
>>
>>
>> On 18 May 2010, at 4:19pm, Black, Michael (IS) wrote:
>>
>>> Interesting...but that logic means that later processes might get their
>>> results before earlier ones.
>>
>> There is no harm in this. In fact it's a characteristic of parallel
>> systems. If it truly mattered which order the results arrived in, you would
>> be running those queries in sequence rather than parallel.
>>
>>> You'll get fairer resolution of busy contention with a fixed timeout. Just
>>> do 10ms 50 times. That way the first guy in should get the first results.
>>
>>
>> There are two common forms of busy/idle handlers: one is exponential backoff
>> (which is what the OP described) and the other is random backoff). Both
>> will occasionally produce results where the second query gets answered
>> first. Fixed delays don't work very well: if they clashed the first time,
>> they'll probably clash the second time because they both paused for exactly
>> the same amount of time.
>>
>> Simon.
>> _______________________________________________
>> 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
>>
>>
> _______________________________________________
> 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
>
>
_______________________________________________
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
