Date: Fri, 23 Nov 2007 08:34:26 -0800 From: Julian Elischer <julian@elischer.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: Attilio Rao <attilio@freebsd.org>, Max Laier <max@love2party.net>, Stephan Uphoff <ups@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: rwlocks, correctness over speed. Message-ID: <47470112.8090005@elischer.org> In-Reply-To: <4746FC5B.3040809@elischer.org> References: <20071121222319.GX44563@elvis.mu.org> <200711221641.02484.max@love2party.net> <3bbf2fe10711220753u435ff4cbxa94d5b682292b970@mail.gmail.com> <200711221726.27108.max@love2party.net> <20071123082339.GN44563@elvis.mu.org> <4746FC5B.3040809@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > Alfred Perlstein wrote: >> * Max Laier <max@love2party.net> [071122 14:40] wrote: >>> On Thursday 22 November 2007, Attilio Rao wrote: >>>> 2007/11/22, Max Laier <max@love2party.net>: >>>>> rwlocks are already used in places that do recursive reads. The one >>>>> place I'm certain about is pfil(9) and we need a proper sollution for >>>>> this. Before rwlocks were used, I had a handrolled locking that >>>>> supported both read/write semantics and starvation avoidance - at the >>>>> cost of failing to allow futher read access when a writer asked for >>>>> access. This however, was quite application specific and not the >>>>> most efficient implementation either. >>>> I'm not a pfil(9) expert, but for what I've heard, rmlocks should be >>>> really good for it, shouldn't them? >>>> >>>> The concept is that if we want to maintain fast paths for rwlock we >>>> cannot do too much tricks there. And you can really deadlock if you >>>> allow recursion on readers... >>> How about adding rwlock_try_rlock() which would do the following: >>> 1) Only variant to allow[1] read recursion and ... >>> 2) ... only if no outstanding write requests >>> 3) Let the caller deal with failure >>> >>> This can be implemented statically, so no overhead in the fast path. >>> The caller is in the best position to decide if it is recursing or >>> not - could keep that info on the stack - and can either fail[2] or >>> do a normal rwlock_rlock() which would wait for the writer to enter >>> and exit. >>> >>> [2] In most situation where you use read locks you can fail or roll >>> back carefully as you didn't change anything - obviously. In pfil - >>> for instance - we just dropped the packet if there was a writer waiting. >>> >>> [1] "allow" in terms of WITNESS - if that can be done. >> >> The problem is that there is no tracking in the common case (without >> additional overhead), so you can't know if you're recursing, unless >> you track it yourself. > > recursion is hard for the caller to know because unrelated code could > have done the original calls. > The only way it can know is if there is some generic recursion detection. translation: make recursion as hard as possible, (or disallow) > >> >> -Alfred >> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47470112.8090005>