The underlying issue with thread misbehaviour is that POSIX file locks are process specific, not thread specific requiring some tormented logic . You only need the POSIX locks if you have multiple access to the same database and are writing to the database.

If you have a multi-threaded application and synchronize access using pthread rwlocks or on Windows read/write locks made from a mutex and event or semaphore then you can ignore the POSIX locks. If your traffic rate is not very high you can just use a mutex around the Sqlite calls for synchronization.

In our threaded applications we use either rwlocks or a mutex and have the bonus of not having to add application logic to handle a BUSY state and endure busy waits and other polling indignities since the threads just block when there is contention.

If you have network connected files (like SMB or NFS) or multiple processes on one machine you will need the POSIX locks.

Mark Brown wrote:
Hi-

We have an application that wraps SQLite 3.4.1.  Due to some vxWorks
platform issues with non-standard posix behavior, we are considering
compiling SQLite with THREADSAFE = 0, and then having our application make
sure that only one thread can access SQLite at a time.  I was wondering
about the restriction regarding moving database connections across threads.

From the FAQ:

"The restriction on moving database connections across threads was relaxed
somewhat in version 3.3.1.  With that and subsequent versions, it is safe to
move a connection handle across threads as long as the connection is not
holding any fcntl() locks. You can safely assume that no locks are being
held if no transaction is pending and all statements have been finalized."
Our application has one thread that opens the database connection and other
threads that use the connection to execute SQL.  All statements are created
at start-up, executed as needed, and then finalized on shutdown.  So, we do
violate the finalize criteria mentioned above.  However, does this still
apply if THREADSAFE = 0?

Let's assume that our application can correctly protect from multiple
threads executing code in the SQLite library at the same time, and also
allows only one transaction to occur at a time.

Thanks for your help,
Mark



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



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

Reply via email to