[Stupid] question about OS locks

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:

...

> When updating the hashcache it does seem possible that we can do it in
> place and without needing read locks.  All we update is the stat
> fingerprint and the file hash.  I assert that this is possible because
> the worst that can happen is that the reader sees one record which has
> been partially updated.  The worst that can happen is that the reader
> will see an incorrect value, and decide to re-read the file.

^- Correct. We could update just the hash-cache fields without
write-locks. In the worst case if they are inconsistent, they would get
regenerated.

Well, there is a slight race condition, that you could update the
"packed_stat" before you updated the "sha1" (it does come first in the
file). So a reader would not notice that a file has been updated.

So if you ran "bzr status" 2 times, the first would notice the new
mtime, and update the fields. The second one would see an updated mtime,
but the old sha1 so it wouldn't try to re-read the file.

Actually, the real problem is if the second status writes out the
dirstate file (because it recognized some other change). Then that file
would be marked "unchanged". Because the mtime would have been updated,
and the old sha1 written. The workaround is a simple "touch" to get us
to scan that file again.


But there is a significant race condition. One solution would be to
change the order of the fields / order of writing. So we write the new
sha1 before we write the stat value.


> 
> (In passing perhaps all we really need to store for text files is not
> the sha1 of the content but just a bit saying "modified from parent or
> not"?)
> 
> If we did this then presumably processes doing logical read operations
> would need to still take the lockdir to update the hashcache fields.
> 

Well, "logical read" operations are taking out an OS write-lock to
update the hash-cache. ('bzr status' will take out a write lock if it
thinks things have changed). If they fail to grab the lock, they just
exit quietly. What we really want is a way to tell "this is a trivial
hash-cache update" versus "this is an important 'add' that you should
complain about if you can't write".

Though for "add" the file should be write-locked before we even start
reading it.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGI5nAJdeBCYSNAAMRAsI3AJwO2royjnsmUHL0i8ReB4CL6askTACglPlI
Gmfgo6mNxCzk9yg2ce0h10A=
=Zs6e
-----END PGP SIGNATURE-----