/ Check-in [0fab65c7]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:More details on the comment justifying the aleged data race in the WAL-mode checkpoint logic.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 0fab65c79f675c825ed7e85c82b65ce6f990c9d0796ebb3886942d241df7b268
User & Date: drh 2019-11-27 20:40:44
Context
2019-11-29
12:51
Fix the parse.sql output file so that it is readable into a database where foreign keys are enforced. check-in: 3a82c554 user: drh tags: trunk
2019-11-27
20:40
More details on the comment justifying the aleged data race in the WAL-mode checkpoint logic. check-in: 0fab65c7 user: drh tags: trunk
2019-11-26
14:24
Fix various documentation typos suggested by Mark Benningfield. No changes to code. check-in: 08f09dc4 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to src/wal.c.

1820
1821
1822
1823
1824
1825
1826
1827












1828
1829
1830
1831
1832
1833
1834
      /* Thread-sanitizer reports that the following is an unsafe read,
      ** as some other thread may be in the process of updating the value
      ** of the aReadMark[] slot. The assumption here is that if that is
      ** happening, the other client may only be increasing the value,
      ** not decreasing it. So assuming either that either the "old" or
      ** "new" version of the value is read, and not some arbitrary value
      ** that would never be written by a real client, things are still 
      ** safe.  */












      u32 y = pInfo->aReadMark[i];
      if( mxSafeFrame>y ){
        assert( y<=pWal->hdr.mxFrame );
        rc = walBusyLock(pWal, xBusy, pBusyArg, WAL_READ_LOCK(i), 1);
        if( rc==SQLITE_OK ){
          pInfo->aReadMark[i] = (i==1 ? mxSafeFrame : READMARK_NOT_USED);
          walUnlockExclusive(pWal, WAL_READ_LOCK(i), 1);







|
>
>
>
>
>
>
>
>
>
>
>
>







1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
      /* Thread-sanitizer reports that the following is an unsafe read,
      ** as some other thread may be in the process of updating the value
      ** of the aReadMark[] slot. The assumption here is that if that is
      ** happening, the other client may only be increasing the value,
      ** not decreasing it. So assuming either that either the "old" or
      ** "new" version of the value is read, and not some arbitrary value
      ** that would never be written by a real client, things are still 
      ** safe.
      **
      ** Astute readers have pointed out that the assumption stated in the
      ** last sentence of the previous paragraph is not guaranteed to be
      ** true for all conforming systems.  However, the assumption is true
      ** for all compilers and architectures in common use today (circa
      ** 2019-11-27) and the alternatives are both slow and complex, and
      ** so we will continue to go with the current design for now.  If this
      ** bothers you, or if you really are running on a system where aligned
      ** 32-bit reads and writes are not atomic, then you can simply avoid
      ** the use of WAL mode, or only use WAL mode together with
      ** PRAGMA locking_mode=EXCLUSIVE and all will be well.
      */
      u32 y = pInfo->aReadMark[i];
      if( mxSafeFrame>y ){
        assert( y<=pWal->hdr.mxFrame );
        rc = walBusyLock(pWal, xBusy, pBusyArg, WAL_READ_LOCK(i), 1);
        if( rc==SQLITE_OK ){
          pInfo->aReadMark[i] = (i==1 ? mxSafeFrame : READMARK_NOT_USED);
          walUnlockExclusive(pWal, WAL_READ_LOCK(i), 1);