Thanks Jens, yes I didn't take the warnings from the Thread Sanitizer
lightly. Although I'm very confident with the actual implementation (using
thread local dictionaries) and have verified time and again using unit tests
that my code is otherwise thread-safe, I really do think there are perhaps
certain things I'm not totally clear about.
The oddest thing about the thread sanitiser race condition warnings was that
the thread 'reading' the same object was in fact from a 'Query-only'
connection (with PRAGMA query_only=1 set) and the thread 'writing' was
usually the writer. I've compiled SQLite with multi-threaded support and
that didn't seem to help.
Once I added @synchronized(lockObj) { .. } around all my readers and
writers, I stopped getting these warnings from the sanitiser. Database
corruption stopped for one user but instead got replaced by disk I/O errors.
Since then I've now disabled all the statement caching as well. Thread local
instances are guaranteed to belong to that particular thread, but I'm no
longer taking any chances. I'm now preparing a new statement and finalising
it immediately inside of a synchronised block of code. Going to try if this
works, but in effect months of 'clever engineering' has been replaced with a
bunch of ugly synchronised blocks that defeat the point of using sqlite with
multi-threading support :)
--
Sent from: http://sqlite.1065341.n5.nabble.com/
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
