I am a student trying to understand the code for LMDB.
One thing I am confused about - there is apparently no mutex for creating a reader transaction. In the function mdb_txn_renew0, which is called by mdb_txn_begin to create the transaction, I see that if we are creating a read-only transaction, we select a meta page without acquiring any mutex. Then, the meta page snapshotted in these lines (and accessed later in the function as well):
/* Copy the DB info and flags */ memcpy(txn->mt_dbs, meta->mm_dbs, CORE_DBS * sizeof(MDB_db));
/* Moved to here to avoid a data race in read TXNs */ txn->mt_next_pgno = meta->mm_last_pg+1;
What happens if a write transaction commits to the meta page while this copy is happening? Isn't it possible that the reader transaction will have copied an inconsistent view of the meta page?
Sincerely, Ruben
ruben.soh@rutgers.edu wrote:
I am a student trying to understand the code for LMDB.
One thing I am confused about - there is apparently no mutex for creating a reader transaction. In the function mdb_txn_renew0, which is called by mdb_txn_begin to create the transaction, I see that if we are creating a read-only transaction, we select a meta page without acquiring any mutex. Then, the meta page snapshotted in these lines (and accessed later in the function as well):
/* Copy the DB info and flags */ memcpy(txn->mt_dbs, meta->mm_dbs, CORE_DBS * sizeof(MDB_db));
/* Moved to here to avoid a data race in read TXNs */ txn->mt_next_pgno = meta->mm_last_pg+1;
What happens if a write transaction commits to the meta page while this copy is happening?
In normal circumstances, it won't, since there are two meta pages used in double-buffer fashion.
Isn't it possible that the reader transaction will have copied an inconsistent view of the meta page?
Only in contrived situations, where the reader thread is forcibly suspended while writers continue to run. This is the situation referenced in the Caveats. http://www.lmdb.tech/doc/
openldap-technical@openldap.org
-
Howard Chu -
ruben.soh＠rutgers.edu