Hi Emerson,

Another remark: On Windows using Events synchronization objects involves
additional kernel context switches and thus slows you down more than
necessary. I'd suggest using a queue, which makes use of the InterlockedXXX
operations (I've implemented a number of those, including priority based
ones - so this is possible without taking a single lock.) or to use critical
sections - those only take the kernel context switch if there really is lock
contention. If you can reduce the kernel context switches, you're
performance will likely increase drastically.

I also don't see the static initialization problem: The queue has to be
available before any thread is started. No thread has ownership of the
queue, except may be the main thread.

Michael


-----Ursprüngliche Nachricht-----
Von: Emerson Clarke [mailto:[EMAIL PROTECTED] 
Gesendet: Mittwoch, 3. Januar 2007 00:57
An: sqlite-users@sqlite.org
Betreff: Re: [sqlite] sqlite performance, locking & threading

Nico,

I have implemented all three strategies (thead specific connections, single
connection multiple threads, and single thread server with multiple client
threads).

The problem with using thread specific contexts is that you cant have a
single global transaction which wraps all of those contexts.  So you end up
having to use fine grained transactions, which decreases performance.

The single connection multiple thread alternative apparently has problems
with sqlite3_step being active on more than one thread at the same moment,
so cannot easily be used in a safe way.  But it is by far the fastest and
simplest alternative.

The single thread server solution involves message passing between threads,
and even when this is done optimally with condition variables (or events on
windows) and blocking ive found that it results in a high number of context
switches and decreased performance.  It does however make a robust basis for
a wrapper api, since it guarantees that things will always be synchronised.
But using this arrangement can also result in various static initialisation
problems, since the single thread server must always be up and running
before anything which needs to use it.

Emerson

On 1/2/07, Nicolas Williams <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 30, 2006 at 03:34:01PM +0000, Emerson Clarke wrote:
> > Technically sqlite is not thread safe.  [...]
>
> Solaris man pages describe APIs with requirements like SQLite's as 
> "MT-Safe with exceptions" and the exceptions are listed in the man page.
>
> That's still MT-Safe, but the caller has to play by certain rules.
>
> Anyways, this is silly.  SQLite API is MT-Safe with one exception and 
> that exception is rather ordinary, common to other APIs like it that 
> have a context object of some sort (e.g., the MIT krb5 API), and not 
> really a burden to the caller.  In exchange for this exception you get 
> an implementation of the API that is lighter weight and easier to 
> maintain than it would have been without that exception; a good 
> trade-off IMO.
>
> Coping with this exception is easy.  For example, if you have a server 
> app with multiple worker threads each of which needs a db context then 
> you could use a thread-specific key to track a per-thread db context; 
> use pthread_key_create(3C) to create the key, pthread_setspecific(3C) 
> once per-thread to associate a new db context with the calling thread, 
> and pthread_getspecific(3C) to get the calling thread's db context 
> when you need it.  If you have a protocol where you have to step a 
> statement over multiple message exchanges with a client, and you don't 
> want to have per-client threads then get a db context 
> per-client/exchange and store that and a mutext in an object that 
> represents that client/exchange.  And so on.
>
> Nico
> --
>
> ----------------------------------------------------------------------
> ------- To unsubscribe, send email to 
> [EMAIL PROTECTED]
> ----------------------------------------------------------------------
> -------
>
>

----------------------------------------------------------------------------
-
To unsubscribe, send email to [EMAIL PROTECTED]
----------------------------------------------------------------------------
-



-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to