On Tue, Sep 06, 2005 at 11:35:50AM +0200, Florian Weimer wrote: > * Francesco P. Lovergine: > > >> SQLite databases (and Subversion repositories) are intended to be > >> opened concurrently by multiple processes. > > > To be more clear: programs which use ordinary file locking to > > syncronize threads need to be fixed. > > I've looked at the SQLite code and it does this. At the same time, it > has to implement recursive locks (which can be entered multiple times > by the same locker, hence it embeds a locker ID (the value returned by > phtread_self) in the lock data structure. This causes the problem > Adeodato described. > > I don't know how to better implement locking for SQLite, given the > constraints. >
Wow, you are trying to render thread-safe a non-thread-safe library, man if I did understand right the terms of the problem. Two, hints: - See flockfile() and its sister calls for stdio functions. - You should add a 'big lock' (based on a single condition variable) entering thread functions which have to have write-access to the per-process locked file (the db itself I suspect?). That would avoid race conditions for non thread-safe code like that. This is not easy, and it would also impact performances. More granularity (i.e. more condition variables to mutex subgroups of functions) you will able to get, more performaces you will gain. BUT, more granularity could seriously create hidden synchronization problems and deadlocks among threads. This is the standard approach to call non-thread-safe legacy libraries within a multi-thread program, briefly. But it's not like a walking in the park... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
