On 5/11/16, Steve Schow <steve at bstage.com> wrote:
>
> Typically concurrency happens when two different users execute their program
> that has sqlite compiled into it;?.. concurrently.
The problem only comes up with two different copies of SQLite are
running within the same process. The same program being run twice is
fine.
The problem is a bug in the posix APIs for file locking. I say "bug".
It is not an implementation problem. The implementation is correct on
all major unix systems. The problem is in the *design*.
In posix, suppose you open a file "xyzzy" and take a lock on that file
using the file descriptor returned by open(). That works fine.
But then if another thread in the same process (technically: another
thread with the same result from getpid()) does this:
close(open("xyzzy"))
The close() operation cancels all locks held on the "xyzzy" file, even
locks created by different threads using different file descriptors.
This is crazy. Everybody acknowledges that it is crazy. But it is the
posix standard.
In order to work around the problem, SQLite has to use global
variables to track every close() operation and defer those that are
against files with locks held by other file descriptors. But if you
have two copies of SQLite in the same address space, they will use
different global variables and may not know about each other, and
hence locks can get cancelled.
--
D. Richard Hipp
drh at sqlite.org
