thread safety of single storage object?

[JCYang]

Is it threadsafe to use a single storage object globally?
I'm using this wrapper in our app. Initially I used thread_local storage object but I occasionally encounter bug which go down to libstdc++ share_ptr trigger segfault(which is quite unlikely a libstdc++ bug). Then I try to build with SQLITE_THREADSAFE=1 and switch to use magic static(global) storage object. One weird error happen, "can not open database file". Then I removed the old file, yet the second error happen, SQL logic error.
I write my own wrapper around the storage object and initialize then sync the scheme in the ctor of the wrapper. Can you please clarify whether the storage object is threadsafe?

[fnc12]

you can read simultaneously but write within a single thread simultaneously with the same connection. So take attention about it. Also storage object itself has a connection object that is opened on every query if it is not. So for multithreading apps it is better to call open_forever once storage is created to keep a single connection

[fnc12]

@JCYang is the issue actual?

[JCYang]

sorry for lack of response so long.
I've found the bug on my side, a typical global object dependency bug.
The static wrapper object owns the storage dies before another static object C while C need to update the database when it is being destructed. Solved by applying nifty counter idiom to the wrapper.
I abandon the thread_local storage idea because I found that sqlite3 has done all the synchronizations for me and my codes do arrange most of the database operations in one thread.
So safe now. Thanks for your response. This issue can be closed now.

[fnc12]

@JCYang thanks for response. Please feel free to post any issue you have.