On 09/21/2017 04:20 AM, Fahad wrote:
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.
If it's the one I think it is, its safe. It happens when a writer
updates the hash table stored in the *-shm file while a reader is
reading it. But the hash table is designed so that:
* To add an entry, a single 32-bit 0x00000000 is overwritten with a
non-zero 32-bit integer is written to the shared-memory, and
* It doesn't matter to the reader whether or not it sees the 0x00 or
the new value
So, although there is a race condition that affects which branch of a
condition the reader takes, both branches are safe.
If you post one of the call stacks we can confirm that that is the error
you're seeing.
Dan.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
