By making THREADSAFE=0 you have not affected the locking, just other
threadsafe capabilities. If you are launching multiple threads I would
make THREADSAFE=1 so that you can be certain that thread safe versions
of library routines are used.
As I see it Sqlite works around POSIX thread restrictions by associating
a connection with a thread so that the process-wide POSIX locks can be
handled by multiple threads.
Our simple way of avoiding these issues was to replace fcntl with an
dummy macro so that it no-ops. Currently we are reworking the os_xxx.c
files to produce a version which uses locks constructed from mutexes,
semaphores and events depending upon the use of Unix or Windows. The
need to make more elaborate locks is to implement the Sqlite RESERVED
lock which gives better concurrency by splitting a write lock into a
lock on the journal and a lock on writing the journal to the database file.
We have an Sqlite-based application server which benefits from having
optimal locking for maximum productivity. Using locking based on the
POSIX model in this multi-threaded application is detrimental,
particularly when there are much more appropriate synchronization
primitives available.
In an earlier workstation-based multi-threaded application we found it
perfectly adequate to just place a mutex around the Sqlite calls to
synchronize access and avoid the dreaded BUSY.
Incidentally the removal of the POSIX locks makes for a version of
Sqlite more appropriate to embedded use by lessening file system
implementation requirements, simplifying application logic and improving
performance.
Mark Brown wrote:
Thanks, John, for your reply. We also had the same idea about wanting to
avoid the SQLITE_BUSY possibilities, and just have callers wait.
So, I think if I understand your response correctly, by having THREADSAFE=0
we have effectively commented out any code that would be trying to use
fcntrl(), and hence, we should have no problem (from a SQLite point of view)
of having multiple threads use the same connection, as long as we are
correctly controlling access to this connection with our own mutexes.
Is that right?
Thanks,
Mark
-----Original Message-----
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 19, 2007 6:54 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Moving database connections across threads
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.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
