进程间SQLite线程安全（在iOS上） [英] Interprocess SQLite Thread Safety (on iOS)
问题描述
我正在尝试确定我的sqlite访问数据库是否在iOS上是线程安全的。我正在编写一个非App Store应用程序（或者可能是一个启动守护程序），因此Apple的批准不是问题。有问题的数据库是内置的 sms.db ，所以肯定操作系统也访问该数据库进行读写。我只想安全地阅读它。
I'm trying to determine if my sqlite access to a database is thread-safe on iOS. I'm writing a non App Store app (or possibly a launch daemon), so Apple's approval isn't an issue. The database in question is the built-in sms.db, so for sure the OS is also accessing this database for reading and writing. I only want to be able to safely read it.
多个进程可以拥有相同的数据库同时打开。
多个进程可以同时执行SELECT。但是，只有
，一个进程可以随时在
时间内对数据库进行更改。
Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however.
我知道线程安全可以用sqlite编译，而 sqlite3_threadsafe（）可以用来测试它。在iOS 5.0.1上运行
I understand that thread-safety can be compiled out of sqlite, and that sqlite3_threadsafe() can be used to test for this. Running this on iOS 5.0.1
int safe = sqlite3_threadsafe();
产生的结果为2. 根据这个，这意味着互斥锁定可用。但是，这并不一定意味着它正在使用中。
yields a result of 2. According to this, that means mutex locking is available. But, that doesn't necessarily mean it's in use.
我不清楚是否在每个连接，每个数据库上动态启用了线程安全性，或者全球基础。
I'm not entirely clear on whether thread-safety is dynamically enabled on a per connection, per database, or global basis.
我也读过这个。看起来像 sqlite3_config（）可用于启用安全的多线程，但当然，我无法控制或了解操作系统本身如何使用此调用（我呢？）。如果我在我的应用程序中再次进行该调用，是否可以安全地读取数据库，或者它是否只会对使用相同<$ c $的多个线程在我的应用程序中进行冲突的冲突c> sqlite3 数据库句柄？
I have also read this. It looks like sqlite3_config() can be used to enable safe multi-threading, but of course, I have no control, or visibility into how the OS itself may have used this call (do I?). If I were to make that call again in my app, would it make it safe to read the database, or would it only deconflict concurrent access for multiple threads in my app that used the same sqlite3 database handle?
无论如何，我的问题是......
Anyway, my question is ...
我可以安全地读取iOS也可以访问的数据库，如果是这样，怎么做？
推荐答案
我从未使用过SQLite，但我花了相当多的时间阅读其文档，因为我计划将来使用它（而且文档很有趣）。我要说线程安全性与多个进程是否可以同时访问同一个数据库文件无关。 SQLite，无论它采用何种线程模式，都将锁定数据库文件，以便多个进程可以立即从数据库中读取，但只有一个可以写入。
I've never used SQLite, but I've spent a decent amount of time reading its docs because I plan on using it in the future (and the docs are interesting). I'd say that thread safety is independent of whether multiple processes can access the same database file at once. SQLite, regardless of what threading mode it is in, will lock the database file, so that multiple processes can read from the database at once but only one can write.
线程安全性仅影响您的进程如何使用SQLite。没有任何线程安全性，您只能从一个线程调用SQLite函数。但是，它应该在写入之前采用EXCLUSIVE锁，以便其他进程不会破坏数据库文件。如果使用多个线程，线程安全只会保护进程内存中的数据不被破坏。因此，我认为您不必担心另一个进程（在本例中为iOS）对SQLite数据库的影响。
Thread safety only affects how your process can use SQLite. Without any thread safety, you can only call SQLite functions from one thread. But it should still, say, take an EXCLUSIVE lock before writing, so that other processes can't corrupt the database file. Thread safety just protects data in your process's memory from getting corrupted if you use multiple threads. So I don't think you ever need to worry about what another process (in this case iOS) is doing with an SQLite database.
编辑：澄清一下，无论何时写入数据库，包括普通的 INSERT / UPDATE / DELETE ，它将自动获取EXCLUSIVE锁，写入数据库，然后释放锁。 （它实际上需要一个SHARED锁，然后是一个RESERVED锁，然后一个PENDING锁，然后写一个EXCLUSIVE锁。）默认情况下，如果数据库已经被锁定（比如说来自另一个进程），那么SQLite将返回SQLITE_BUSY而不等待。您可以致电 sqlite3_busy_timeout（） 告诉它等待更长时间。
To clarify, any time you write to the database, including a plain INSERT/UPDATE/DELETE, it will automatically take an EXCLUSIVE lock, write to the database, then release the lock. (And it actually takes a SHARED lock, then a RESERVED lock, then a PENDING lock, then an EXCLUSIVE lock before writing.) By default, if the database is already locked (say from another process), then SQLite will return SQLITE_BUSY without waiting. You can call sqlite3_busy_timeout() to tell it to wait longer.
这篇关于进程间SQLite线程安全（在iOS上）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
