On Nov 25, 2007, at 5:34 PM, Teufel wrote:
Hi everyone,
I am using sqlite 3.3 awhile now for some statistic updates in
multithreaded enviroment. Now I would like to move on to 3.5.2 use
it more for other tasks too.
Since the sqlite db is placed here on a fs, which has a broken
fcntl, I disabled it by putting "#define fcntl (A,B,C) 0". As I
only use it within the same process with couple of threads, I am
doing currently the locking with pthread mutexes like:
each thread {
/* worker stuff */
...
if new stats did arrive:
compete on mutex
-> when lock is acquired, do
open database
read something (eg sqlite_exec "select ....")
if does not exist, do write (sqlite_exec
"insert into table...")
close database ->
release lock
}
Of course, this is very simple and serializing everything including
open/close of the db image. My question is now, what could I
improve with 3.5.x now as it has buildin thread safety for the same
database (as mentioned in 34to35) but I did not find how this
thread safety is made (using mutexes, rwlock? still fcntl?)
I cannot rely on fcntl, so for thread-safety, it's all up to
pthread mutexes/rwlock
For threads within the same process, fcntl is broken by design in POSIX.
(You can clearly tell which parts of Unix were invented by Thompson
and Richie
and which parts were added later by clueless committees. Posix advisory
locks belong in the latter category.) SQLite contains a work-around to
this problem based on pthreads locks. It should be able to open
multiple connections to the same database within the same process
and use them independently and locking should work correctly. You
should not have to change anything. It should just work.
D. Richard Hipp
[EMAIL PROTECTED]
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
