Are you misreading that line....it's not worded very well. To rephrase in the positive sense instead of the negative.
"provided every thread has its own db connection" -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Ashok Pitambar Sent: Sunday, February 24, 2013 7:44 AM To: Roger Binns; General Discussion of SQLite Database Subject: Re: [sqlite] Thread sync issue Read point 2 multithread carefully it says "provided no single db connection is used simultaneously in two or more threads". I am creating one db connection and it is accessed by multiple threads. I am facing while reading the count from tables. There is mismatch due sync issue. Regards, Ashok ----- Reply message ----- From: "Roger Binns" <rog...@rogerbinns.com> To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org> Subject: [sqlite] Thread sync issue Date: Sun, Feb 24, 2013 1:57 pm -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/02/13 00:14, Roger Binns wrote: > On 23/02/13 21:23, Ashok Pitambar wrote: >> Sqlite doc says it thread safe ... > > http://www.sqlite.org/threadsafe.html > > What makes you think the doc is wrong? One big gotcha: errors - if you use one connection per thread then you are fine. If you use the same connection across threads then read on: The one thing not mentioned is that retrieving SQLite errors is not threadsafe. The operating system does errors as thread specific (eg errno, GetLastError). SQLite does errors as connection wide (I really wish this was fixed). That means getting integer error codes is a race condition as a different thread can change it before your thread has a chance to retrieve it. If you intend to retrieve the error string then your program *could crash* since the pointer you get could end up with invalid memory access when you treat it as a string. Consequently the *only* safe way to make API calls where you intend to look at the error code or string is to add yet another level of locking. You can use sqlite3_db_mutex to get the mutex for a connection, and sqlite3_mutex_enter/leave to keep it locked while you extract codes and messages. For example to safely call a single function (sqlite3_blobopen in this example but it applies to every sqlite3 call that returns an error): int rc=SQLITE_OK; char *errmsg=NULL; sqlite3_mutex_enter(sqlite_db_mutex(db)); rc=sqlite3_blobopen(.....); if(rc!=SQLITE_OK) { rc=sqlite3_extended_errcode(db); errmsg=strdup(sqlite3_errmsg(db); } sqlite3_mutex_leave(sqlite_db_mutex(db)); // now you can safely use rc and errmsg Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlEpztEACgkQmOOfHg372QTfLgCfVzKDib6ExfEhUO7StM5XYWT1 YSAAnRUWckgS95dF+7Rvq1RtU+DS8U7X =LB1g -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
