On Wed, 2 Apr 2008, David Schultz wrote:
On Tue, Apr 01, 2008, Jeff Roberson wrote:
On Wed, 2 Apr 2008, Max Laier wrote:
On Tuesday 01 April 2008 22:31:55 Attilio Rao wrote:
attilio 2008-04-01 20:31:55 UTC
FreeBSD src repository
Modified files:
sys/kern kern_rwlock.c
sys/sys rwlock.h
Log:
Add rw_try_rlock() and rw_try_wlock() to rwlocks.
These functions try the specified operation (rlocking and wlocking)
and true is returned if the operation completes, false otherwise.
hmmm ... I'm certainly missing something here, but what's a possible
usecase for these? It seems there is not much you can do if you can't
obtain a rw_lock. I can understand the need for sx_try_* where you want
to avoid sleeping, but I can't figure out the need for it on a locking
primitive that will only spin or wait (not 100% sure about the
terminology here). This is especially strange for rw_try_wlock, unless
you plan to sleep manually on fail. But then again you'd have a good
chance that you have to do it over and over again if timing is
unfortunate.
I asked for it. We have a try operation for mtx already. I was
experimenting with converting some code to use rwlocks from mtx and it
required it. The specific case is in the softdep code where it uses
trylock to avoid deadlocking. With trylock you can violate the lockorder.
One reason that many systems don't provide a rw_try_wlock()
primitive is that a constant stream of readers can easily starve
threads attempting to acquire the write lock without waiting.
There are probably situations where this isn't a problem, though,
e.g., if readers rarely hold the lock for a long time...
The same applies to constant streams of lockers with a normal mutex. We
have found a few cases now where trylock was used that basically never
succeeded and caused pessimal behavior. I'm not really a fan of it myself
but it is (ab)used in some scenarios and having it in rw will make
changing from mtx easier.
I think it would be a good task for someone to attempt to remove uses of
trylock by restructuring the locking.
Thanks,
Jeff
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
