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
