Lockless uidinfo.

Pawel Jakub Dawidek pjd at FreeBSD.org
Sat Aug 18 10:28:26 PDT 2007


On Sat, Aug 18, 2007 at 10:17:38AM -0700, Alfred Perlstein wrote:
> * Pawel Jakub Dawidek <pjd at FreeBSD.org> [070818 09:14] wrote:
> > On Sat, Aug 18, 2007 at 08:50:41AM -0700, Alfred Perlstein wrote:
> > > * Pawel Jakub Dawidek <pjd at FreeBSD.org> [070818 07:59] wrote:
> > > > Yes, to lookup uidinfo you need to hold uihashtbl_mtx mutex, so once you
> > > > hold it and ui_ref is 0, noone will be able to reference it, because it
> > > > has to wait to look it up.
> > > 
> > > And the field doesn't need to be volatile to prevent cached/opportunitic
> > > reads?
> > 
> > The only chance of something like this will be the scenario below:
> > 
> > thread1 (uifind)		thread2 (uifree)
> > ----------------		----------------
> > 				refcount_release(&uip->ui_ref))
> > 				/* ui_ref == 0 */
> > mtx_lock(&uihashtbl_mtx);
> > refcount_acquire(&uip->ui_ref);
> > /* ui_ref == 1 */
> > mtx_unlock(&uihashtbl_mtx);
> > 				mtx_lock(&uihashtbl_mtx);
> > 				if (uip->ui_ref > 0) {
> > 					mtx_unlock(&uihashtbl_mtx);
> > 					return;
> > 				}
> > 
> > Now, you suggest that ui_ref in 'if (uip->ui_ref > 0)' may still have
> > cached 0? I don't think it is possible, first refcount_acquire() uses
> > read memory bariers (but we may still need ui_ref to volatile for this
> > to make any difference) and second, think of ui_ref as a field protected
> > by uihashtbl_mtx mutex in this very case.
> > 
> > Is my thinking correct?
> 
> I don't know, that's why I was asking you. :)

In previous version of the patch I had atomic_load() in there, but after
some thinking I decided it's not needed and I change it. Now, that you
asked about it I was afraid that maybe my thinking isn't correct.
Anyway, it'll be good if someone could confirm it's ok.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20070818/44501162/attachment.pgp


More information about the freebsd-arch mailing list