Been following this a while... You have access to the source, and apparently are a "threading genius." Please make the required minor changes and post a link here so we can all benefit.
Fred > -----Original Message----- > From: Emerson Clarke [mailto:[EMAIL PROTECTED] > Sent: Saturday, December 30, 2006 9:34 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] sqlite performance, locking & threading > > > Roger, > > I think sqlite suffers somewhat from a bit of an identity crisis. > Whilst it is both a library and a piece of code which you embed in a > project it is often talked about as though it is some external > component. > > Technically sqlite is not thread safe. Just because the library has > explicitly disallowed using the same sqlite3 * structure in multiple > threads on some platforms (i understand this requirement has been > relaxed on others) does not make it thread safe. Even on the > platforms where a single sqlite3 * structure can be used on multiple > threads (provided it is not at the same time), it is not possible to > have a transaction which works across these threads. So even if the > connection is thread safe, the transactions are not. > > By the usual definition, something which is thread safe can be safely > used across multiple threads, usually with the aid of synchronisation > but sometimes not. For instance collections are often considdered > thread safe only when they manage their own mutexes internally so that > the user doesnt have to. But either way, you can use them accross > multiple threads. You cannot do this with sqlite, so it is quite > confusing to say that sqlite is thread safe... > > I think a better definition would be that sqlite can be safely used in > a multithreaded program, but is not thread safe. > > I agree that multithreaded programming can be difficult, but its not > magic and i think that a few simple rules can overcome most of the > problems. It certainly is not luck that multithreaded systems work, > usually its the result of careful design and hard work. > > Emerson > > On 12/30/06, Roger Binns <[EMAIL PROTECTED]> wrote: > > Emerson Clarke wrote: > > > If i have a linked list, i can use it across threads if i want to, > > > provided that i synchronise operations in such a way that the list > > > does not get corrupted. > > > > And of course you also have to know about memory barriers > and compiler > > re-ordering. That is highly dependent on the libraries > and/or compiler > > you are using, as well as underlying hardware > implementation. Most of > > the time, developers just get lucky. > > > > http://en.wikipedia.org/wiki/Memory_barrier > > > > > Likewise for most other data structures and libraries. > > > > Arguably that is by luck and not design! Look at the > effort that to go > > in an add _r suffixed versions of several functions in the standard > > libraries. And many GUI libraries have long had a > restriction that you > > can only use them in one thread. > > > > > Sqlite does not follow these rules, as something created > in one thread > > > does not work in another thread regardless of > synchronisation and it > > > is out of my control. > > > > SQLite's design was not "luck". The design expects you to > create unique > > sqlite3 objects in each thread. Effort and thought was put > into that! > > > > http://www.sqlite.org/cvstrac/wiki?p=MultiThreading > > > > It was loosened a bit in 3.3.x: > > > > http://www.sqlite.org/faq.html#q8 > > > > What isn't allowed is multiple statements executing at the > same time in > > multiple threads against the same sqlite3* db object. In order to > > support that, SQLite would have to have extensive code > protecting the > > various internal data structures as well as ensuring concurrency. > > > > > This is not a situation that i would expect anyone to purposefully > > > design becuase it makes multithreaded programming difficult, > > > > The purposeful design is that you make sqlite3 objects per > thread. That > > way there is absolutely no danger of corruption or other bad issues. > > > > Roger > > > > > > > -------------------------------------------------------------- > --------------- > > To unsubscribe, send email to [EMAIL PROTECTED] > > > -------------------------------------------------------------- > --------------- > > > > > > -------------------------------------------------------------- > --------------- > To unsubscribe, send email to [EMAIL PROTECTED] > -------------------------------------------------------------- > --------------- > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
