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