On Mon, Jun 11, 2001 at 11:45:07AM +0100, David Reid wrote: > > This thread is getting rather long, but I don't see the motivation. > > > > What is the requirement for this range locking?
multiple threads accessing same memory range. see tdb for the motivation. tdb is gdbm-like simultaneous reader, simultaneous WRITER [unlike all of the other *dbm databases, which have funny things like, if you write to this db, all bets are off. ??? :)] db-access, with optional mmap support. the implementation for the data-access is hash-chains. each hash-chain is *individually* locked, with a byte-range posix lock. they have some intriguing double-dealing with enumeration, and are not recommending the use of the first/next as a result, but recommend using the tdb_traverse() instead. anyway. if an sms-implementor of an mmap or thread-accessed memory module decided to optimise it by having the admin-memory byte-range-locked, that should be their choice to be able to do that. by not providing an sms->range_lock() fn, or equiv., that optimisation possibility is pretty much guaranteed ruled out. in a stackeable manner, anyway. > We don't have to do > > everything imaginable simply because we can. Every time we load "features" > > into APR(UTIL), that just means we need to maintain them. Why do we *need* > > this feature? And will it be widely useful? do you think that allowing [sms] Developers to optimise memory-administrative management is good? and if so, does that help justify providing range locking in sms? > > I'm not seeing it. that's because i didn't explain/justify why i was recommending it. which would help :) luke
