On 9/24/15, T?r?k Edwin <edwin+sqlite3 at etorok.net> wrote: > Hi, > > When -DSQLITE_THREADSAFE=0 is used then unixShmBarrier becomes a noop > because unixEnterMutex/unixLeaveMutex are empty functions.
Good observation. This problem is addressed by https://www.sqlite.org/src/info/c6ab807b72ddfc14 Note that if unixShmBarrier does not work, then that does not guarantee problems. It only opens up the possibility of a race condition. Further observe that this deficiency has existed in the Fossil instances that run SQLite's version control system use WAL mode and are compiled with SQLITE_THREADSAFE=0 and they have run for many years without issues. So it is probably not a severe problem, but it is worth fixing. > Digging through the SQLite source code I found this comment: > > /* Read the header. This might happen concurrently with a write to the > ** same area of shared memory on a different CPU in a SMP, > ** meaning it is possible that an inconsistent snapshot is read > ** from the file. If this happens, return non-zero. > ** There are two copies of the header at the beginning of the wal-index. > ** When reading, read [0] first then [1]. Writes are in the reverse order. > ** Memory barriers are used to prevent the compiler or the hardware from > ** reordering the reads and writes. > */ > > IIUC then with SQLITE_THREADSAFE=0 on an SMP system with a database in WAL > mode SQLite wouldn't be able to detect > that an inconsistent snapshot is read. > > Should this be documented, and how serious would be the consequences of > reading an inconsistent snapshot there? > Would it be recommended to always build applications that use WAL with > SQLITE_THREADSAFE!=0? > > > Best regards, > --Edwin > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp drh at sqlite.org
