sqlite with multithreads
當多個執行緒訪問某個方法時，不管你通過怎樣的呼叫方式、或者說這些執行緒如何交替地執行，我們在主程式中不需要去做任何的同步，這個類的結果行為都是我們設想的正確行為，那麼我們就可以說這個類是執行緒安全的。
多個程序可以同時開啟同乙個資料庫。多個程序可以同時執行select。但是，只有乙個程序可以隨時對資料庫進行更改。
sqlite使用讀取器/寫入器鎖來控制對資料庫的訪問。（在win95 / 98 / me下，缺少對讀取器/寫入器鎖的支援，而是使用概率模擬。）但請注意：如果資料庫檔案儲存在nfs檔案系統上，則此鎖定機制可能無法正常工作。這是因為許多nfs實現都會破壞fcntl（）檔案鎖定。如果多個程序可能同時嘗試訪問該檔案，則應避免將sqlite資料庫檔案放在nfs上。在windows上，microsoft的文件說如果您沒有執行share.exe守護程式，則在fat檔案系統下鎖定可能不起作用。對windows有很多經驗的人告訴我，網路檔案的檔案鎖定是非常錯誤的，並且不可靠。如果他們說的是真的，
我們知道沒有其他嵌入式 sql資料庫引擎支援與sqlite一樣多的併發性。sqlite允許多個程序一次開啟資料庫檔案，並允許多個程序一次讀取資料庫。當任何程序想要寫入時，它必須在更新期間鎖定整個資料庫檔案。但這通常只需要幾毫秒。其他流程只是等待作者完成然後繼續他們的業務。其他嵌入式sql資料庫引擎通常只允許單個程序一次連線到資料庫。
但是，客戶端/伺服器資料庫引擎（如postgresql，mysql或oracle）通常支援更高階別的併發性，並允許多個程序同時寫入同一資料庫。這在客戶端/伺服器資料庫中是可能的，因為總有乙個良好控制的伺服器程序可用於協調訪問。如果您的應用程式需要大量併發，那麼您應該考慮使用客戶端/伺服器資料庫。但經驗表明，大多數應用程式需要的併發性遠低於設計人員的想象。
當sqlite嘗試訪問由另乙個程序鎖定的檔案時，預設行為是返回sqlite_busy。您可以使用sqlite3_busy_handler（）或sqlite3_busy_timeout（） api函式從c**調整此行為 。
精簡版:
對於讀操作:多個程序可以同時進行資料庫的查詢。
對於寫操作:同一時間只有乙個程序可以進行寫操作。
多程序寫操作在以下情況下可能會導致錯誤:
執行緒是**的。避免他們。
sqlite是執行緒安全的。我們做出這種讓步，因為許多使用者選擇忽略前一段中給出的建議。但為了保證執行緒安全，必須在sqlite_threadsafe預處理器巨集設定為1的情況下編譯sqlite。分發中的windows和linux預編譯二進位制檔案都是以這種方式編譯的。如果您不確定要鏈結的sqlite庫是否被編譯為執行緒安全，您可以呼叫sqlite3_threadsafe（） 介面來查詢。
sqlite是執行緒安全的，因為它使用互斥鎖來序列化對公共資料結構的訪問。但是，獲取和釋放這些互斥鎖的工作會使sqlite略微減慢。因此，如果您不需要sqlite是執行緒安全的，則應禁用互斥鎖以獲得最佳效能。有關其他資訊，請參閱執行緒模式文件。
在unix下，你不應該通過fork（）系統呼叫將乙個開放的sqlite資料庫帶入子程序。
簡單來說，從3.3.1版本開始，它就是執行緒安全的了。
threadsafe就是指在設定正確的前提下，多執行緒同時訪問sqlite並不會影響資料庫的完整性，而不是說每個執行緒對資料庫所有的操作都可以保證正確執行。
SQLite 多執行緒
sqlite支援3種執行緒模式 單執行緒 這種模式下，沒有進行互斥，多執行緒使用不安全。禁用所有的mutex鎖，併發使用時會出錯。當sqlite編譯時加了sqlite threadsafe 0引數，或者在初始化sqlite前呼叫sqlite3 config sqlite config singlet...
關於sqlite多執行緒
1 如果是sqlite open fullmutex，也就是序列化方式，則對於連線時互斥的，只有乙個連線關閉，另外乙個連線才能讀寫 2 如果是sqlite open nomutex，則是多執行緒模式，對於寫是互斥的，但是如果乙個連線持續寫，另外乙個連線是無法寫入的，只能是錯誤或者超時返回。不過乙個連...
SQLite多執行緒使用
sqlite支援3種執行緒模式 單執行緒 這種模式下，沒有進行互斥，多執行緒使用不安全。禁用所有的mutex鎖，併發使用時會出錯。當sqlite編譯時加了sqlite threadsafe 0引數，或者在初始化sqlite前呼叫sqlite3 config sqlite config singlet...