On Wednesday 02 April 2008 00:52:45 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.
Makes sense, thanks! A little follow-up, though about something I'm wondering about for quite some time now. Take the following scenario: Thread A: rw_rlock(RW) ... mtx_lock(MTX) ... UNLOCK Thread B: mtx_lock(MTX) ... rw_rlock(RW) ... UNLOCK Thread C: rw_wlock(RW) ... UNLOCK Can this deadlock? How? If thread C did: rw_wlock(RW) ... mtx_lock(MTX) ... UNLOCK or the other way around, I can see that it will[1] deadlock, but with the wlock without a lock order wrt the MTX, I can't see it. Plus, can we teach WITNESS to keep quite about thread A and B unless we also see a lock order with the wlock and the mutex? [1] In fact, thinking about it right now ... if thread C did: mtx_lock(MTX) ... rw_slock(RW) ... UNLOCK it might still be okay. IIRC we allow rlocks to succeed as long as there are other rlocks held. Though this might be historical behavior to support recursion. I see that we wouldn't want to rely on this to avoid live locks. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"