On Fri, 23 Mar 2001, David Harris wrote:

> Stas,
>
> Sounds like you agree with me that downgrading locks from exclusive to
> shared is not a problem with the method I described in the last e-mail.

That's correct.

> Now you have a concern with upgrading locks from shared to exclusive:
>
> > David, please consider this scenario:
> >
> > ... At some point in time, processes A and B both read from the dbm via SH
> > lock.
> >
> > 1. A completes its reading and unlocks the DBM, while still having the
> > first 4k cached. (A still has the dbm tie()'d.
> >
> > 2. B wants to write, so it requests an EX lock and gets it granted.
>
> This will not happen. When B requests the EX lock it will block until all of
> the other shared locks have been released. Process A has to release the SH
> lock somehow for B to get the EX lock. Either A simply finishes and releases
> the lock, or A requests an upgrade, is denied, and handles this by releasing
> the lock.

That's if you code it that way. Nothing prevents you from unlocking A, and
then asking for some lock later. You always want to make the critical
section as short as possible. So if you need to access the dbm file twice
through the request. You may go through this scenario:

A: flock SH
B: flock SH
A: flock UN
B: flock EX
B: flock SH
A: flock SH

'A' still have the data cached and possibly invalid.

Your proposed system is clean only in this case:

You can never explicitly unlock dbm and then relock it without calling
untie(). You can safely upgrade the lock from SH to EX and downgrade from
EX to SH though, without using UN (sort of semi-atomically).

> When the EX lock is granted (whether from an upgrade or not), by definition
> no other processes can have a SH lock and be reading the database. No other
> processes can have a first 4k cached because no other processes can have the
> file open.

They can, if there weren't untie()d per my above explanation.

_____________________________________________________________________
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/


Reply via email to