apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: SDBM locking...
Date Sun, 13 May 2001 11:17:02 GMT
On Sat, May 12, 2001 at 07:48:02PM -0700, Justin Erenkrantz wrote:
>...
> What is the status of the SDBM locking code?  I know that Bill
> committed some stuff to implement reference counting and other 
> things.  I'm not sure if he finished that commit or not (I think so).

It is done except that I saw a problem in apr_sdbm_firstkey(). Need to hear
from Bill in case he had something in mind that I'm missing.

> In my "tests" (if you could call them that), the mod_mbox code is 
> spending a lot of time obtaining and releasing file locks related to the
> SDBM code (besides writing to the network).  Is there any plan to 
> implement either a fast path without locking or to somehow address the 
> locking speed?

The original code would lock the file when you called apr_sdbm_open() and
release it when you called apr_sdbm_close() (or waited for a pool cleanup).
That behavior continues to exist *unless* you happen to pass APR_SHARELOCK
into apr_sdbm_open().

If you *do* pass APR_SHARELOCK, then it will grab/release the lock for each
operation. The intent is to spend the time opening the file just once (say
in read/write mode), then do a bunch of read operations and occasionally a
write operation. This mode prevents holding a write (exclusive) lock for the
duration of the app.

> Wouldn't it be possible to just hold the file lock for the duration that
> we have the SDBM open rather than obtaining and releasing it at every
> call?

Yes. That is the original behavior, and post-wrowe locking, it is the
default without SHARELOCK.

> So, if you open with an exclusive lock, you get an exclusive file
> lock on the DBM until you close it.  The file handle is open at all points,
> so I'm not sure what the logic is for getting and releasing the file
> lock at each call - the cache is almost useless because it'll be
> invalidated all the time.

Yes, the cache is toast, but you do avoid the open/close all the time. That
is usually a bit more expensive than read/write to a file (e.g. to keep
reading in the page to the (invalidated) cache).

> If a shared lock on that file exists, exclusive locks will block until
> the shared locks are released (shared locks should not be affected), and
> if an exclusive lock is held by someone, everyone waits until it is
> released.

Right. That was the original locking behavior that I implemented on the
original SDBM.

> Or, is there a drawback to this that I am not seeing?  -- justin

open/close is relatively expensive. So you want to avoid per-operation
opening. But if you need to (occasionally) do a write, then you would need
to open exclusively which will block all the other guys.

Note that apr_sdbm_lock and apr_sdbm_unlock have been exported to the API.
That allows you to do a single lock, a bunch of operations (where the per-op
lock/unlock is fast (refcounted)), then a single unlock. This can also be
nice for transactional purposes.

Does that answer your questions/issues?

And re: the lock contention you're seeing: check to make sure you aren't
passing SHARELOCK. Without that, there should be just a single lock/unlock
on the file.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message