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