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 |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
0fab65c79f675c825ed7e85c82b65ce6 |
| User & Date: | drh 2019-11-27 20:40:44.618 |
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: 3a82c554c3 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: 0fab65c79f user: drh tags: trunk) | |
|
2019-11-26
| ||
| 14:24 | Fix various documentation typos suggested by Mark Benningfield. No changes to code. (check-in: 08f09dc4f9 user: drh tags: trunk) | |
Changes
Changes to src/wal.c.
| ︙ | ︙ | |||
1820 1821 1822 1823 1824 1825 1826 |
/* 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
| | > > > > > > > > > > > > | 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);
|
| ︙ | ︙ |