On Thu, 22 Mar 2001, David Harris wrote:
Thanks, David!
> I have done some investigation of the sync method in DB_File and this is
> what I have determined: the sync method only writes cached information out
> to disk. Information already cached in the process is not invalidated
> causing a re-read from the disk.
>
> My example program and the annotated strace can be found here for anyone
> that wants to see the details:
>
> http://www.davideous.com/misc/dblockflaw-1.2-checksync/synctest.pl
> http://www.davideous.com/misc/dblockflaw-1.2-checksync/synctest.strace01
>
> Here is what I think this means for locking:
>
> If you want to downgrade a lock from exclusive to shared, sync the database
> and change the lock status. This will allow other readers access to a
> fully-written database. No one else will be allowed to write the database
> (requiring your process to have invalidated any cached data) until you have
> released the shared lock. No problem there.
Are you sure? Doesn't it contradict with the fact that other readers have
already cached the first 4k of data? And you have modified the database
and possibly the first 4k during the write, so if this is the case, now
readers have the wrong 4k in their cache.
Or do you mean that when a process that switches from EX to SH, doesn't
need to re-tie(), since it has *its* cache valid. Other process do need to
re-tie when acquiring any kind of lock, if they don't have none yet.
The rest seems to be correct.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
