> Your reply suggests this scenario IS supported, and the crash is probably due to my code violating the concurrent requirement. Exactly. I can state it no better than Keith's "If you use SQLITE_OPEN_FULLMUTEX and the crashes go away, then the problem is isolated to your re-implementation of SQLITE_OPEN_FULLMUTEX". > 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. That's not precisely the requirement. Different threads may use a shared connection **IF AND ONLY IF** they do not execute (most) SQLite code concurrently. Without the protection against reentrancy effected when the library guards against such using a mutex, prevention of conflicting access to its data structures (including the DB itself) is up to the client code. The reason that SQLITE_OPEN_NOMUTEX exists is that multithreaded applications often have their own guards against deleterious reentrancy for their own data structures which may include something like a SQLite connection. In such cases, fiddling with a (likely additional) mutex would be superfluous and a waste of code space and time.