I'm still confused by your extensive response. Suppose the application is following: 1. 2 threads: T1, T2 2. One mutex: M. 3. Opened one connection to an SQLite database: C, with flag SQLITE_OPEN_NOMUTEX. Now for a thread to access the database, it needs to: 1. Acquire lock on M. 2. Execute SQL on C: the execution is always `BEGIN TRANSACTION;` and then do some stuff, and finally `COMMIT`. 3. Release lock on M. In this situation, random crash could happen on some of my target platforms, like Linux CentOS 7 and MacOS 10.14. If I inspect the thread stacks, it's only one thread inside SQLite code where BAD ACCESS happens, the rest threads are usually just sleeping. (Strangely on Windows and QNX, even I run the program like 2 days, no crash happened yet.) My conclusion from my experience is that `SQLITE_OPEN_NOMUTEX` does not support this, because this scenario means both T1 and T2 would access C, although there is no concurrent accessing to C because application protects it with M. Your reply suggests this scenario IS supported, and the crash is probably due to my code violating the concurrent requirement. I suppose the requirement is that to use `SQLITE_OPEN_NOMUTEX`, both T1 and T2 needs to open their own connection (e.g. C1 and C2) to the database, and a thread needs to stick to using its own connection.