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/
