[EMAIL PROTECTED] wrote:
John Stanton <[EMAIL PROTECTED]> wrote:
When using multiple threads you must use synchronization. Apart from
the usual thread safety issues you need to sync access to Sqlite. You
can use the Sqlite BUSY feature for that or use thread primitives.
Beginning with 3.5.0, the synchronization is built-in. You can
call SQLite APIs with abandon and everything should just work.
There are some exceptions to this noted in the C-API documentation.
But for the most part, there is no need for the application to
worry with thread locking in SQLite 3.5.
If you choose to use threads in your application, that means
that your application will probably run slower and contain
more bugs, especially bugs that are hard to reproduce and harder
to fix. But by moving to SQLite version 3.5, you are less
likely to have bugs in the database, at least.
--
D. Richard Hipp <[EMAIL PROTECTED]>
Your wise advice on thread usage is very pertinent. Users have a way of
assigning magical properties to threads and expect to speed up their
processing merely by having multiple threads.
Threads are a way of sharing resources, at some execution expense, and
should be used accordingly. The overhead of synchronizing access to
shared resources is not trivial and eliminating race conditions can be
challenging.
When multi-processor machines are used thread usage may indeed implement
parallel processing when used appropriately and have tangible benefits.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
