Something in a higher level language (e.g., Python) that is easy to run maybe better. Or at least some stand-alone C code (compilable to executables) that is solely for the purpose of demonstrating the locking mechanism. The descriptions in os_unix.c don't satisfy these conditions. Just based on them, it is hard for me to make my own toying implementation on the locking mechanism to understand the nuts and bolts.
On 7/3/19, Keith Medcalf <kmedc...@dessus.com> wrote: > > On Wednesday, 3 July, 2019 11:59, Peng Yu <pengyu...@gmail.com> wrote: > >>As I said in my original message "I am trying to understand how lock >>is implemented in sqlite3". > > from os_unix.c: > > /* The following describes the implementation of the various locks and > ** lock transitions in terms of the POSIX advisory shared and exclusive > ** lock primitives (called read-locks and write-locks below, to avoid > ** confusion with SQLite lock names). The algorithms are complicated > ** slightly in order to be compatible with Windows95 systems > simultaneously > ** accessing the same database file, in case that is ever required. > ** > ** Symbols defined in os.h indentify the 'pending byte' and the 'reserved > ** byte', each single bytes at well known offsets, and the 'shared byte > ** range', a range of 510 bytes at a well known offset. > ** > ** To obtain a SHARED lock, a read-lock is obtained on the 'pending > ** byte'. If this is successful, 'shared byte range' is read-locked > ** and the lock on the 'pending byte' released. (Legacy note: When > ** SQLite was first developed, Windows95 systems were still very common, > ** and Widnows95 lacks a shared-lock capability. So on Windows95, a > ** single randomly selected by from the 'shared byte range' is locked. > ** Windows95 is now pretty much extinct, but this work-around for the > ** lack of shared-locks on Windows95 lives on, for backwards > ** compatibility.) > ** > ** A process may only obtain a RESERVED lock after it has a SHARED lock. > ** A RESERVED lock is implemented by grabbing a write-lock on the > ** 'reserved byte'. > ** > ** A process may only obtain a PENDING lock after it has obtained a > ** SHARED lock. A PENDING lock is implemented by obtaining a write-lock > ** on the 'pending byte'. This ensures that no new SHARED locks can be > ** obtained, but existing SHARED locks are allowed to persist. A process > ** does not have to obtain a RESERVED lock on the way to a PENDING lock. > ** This property is used by the algorithm for rolling back a journal file > ** after a crash. > ** > ** An EXCLUSIVE lock, obtained after a PENDING lock is held, is > ** implemented by obtaining a write-lock on the entire 'shared byte > ** range'. Since all other locks require a read-lock on one of the bytes > ** within this range, this ensures that no other locks are held on the > ** database. > */ > > So the original advise to read the os.c/os.h, os_common.h, os_unix.c and > os_win.c/os_win.h was valid. Only knowing how to read English prose is > required. > > note: > /os.h indentify/os.h identify/ > /Widnows95/Windows95/ > /selected by from/selected byte from/ > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a > lot about anticipated traffic volume. > > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- Regards, Peng _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
