Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Jun 2013 10:34:11 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r252209 - in head: share/man/man9 sys/kern sys/sys
Message-ID:  <201306271034.11852.jhb@freebsd.org>
In-Reply-To: <51CA97AE.4090306@freebsd.org>
References:  <201306251844.r5PIiFDZ009708@svn.freebsd.org> <51CA97AE.4090306@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, June 26, 2013 3:26:38 am Andre Oppermann wrote:
> On 25.06.2013 20:44, John Baldwin wrote:
> > Author: jhb
> > Date: Tue Jun 25 18:44:15 2013
> > New Revision: 252209
> > URL: http://svnweb.freebsd.org/changeset/base/252209
> >
> > Log:
> >    Several improvements to rmlock(9).  Many of these are based on patches
> >    provided by Isilon.
> >    - Add an rm_assert() supporting various lock assertions similar to other
> >      locking primitives.  Because rmlocks track readers the assertions are
> >      always fully accurate unlike rw_assert() and sx_assert().
> >    - Flesh out the lock class methods for rmlocks to support sleeping via
> >      condvars and rm_sleep() (but only while holding write locks), rmlock
> >      details in 'show lock' in DDB, and the lc_owner method used by
> >      dtrace.
> >    - Add an internal destroyed cookie so that API functions can assert
> >      that an rmlock is not destroyed.
> >    - Make use of rm_assert() to add various assertions to the API (e.g.
> >      to assert locks are held when an unlock routine is called).
> >    - Give RM_SLEEPABLE locks their own lock class and always use the
> >      rmlock's own lock_object with WITNESS.
> >    - Use THREAD_NO_SLEEPING() / THREAD_SLEEPING_OK() to disallow sleeping
> >      while holding a read lock on an rmlock.
> 
> Thanks!
> 
> Would it make sense to move struct rm_queue from struct pcpu itself to
> using DPCPU as a next step?

Perhaps.  It might make pcpu.h cleaner, aside from that concern I don't think
it really matters much.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201306271034.11852.jhb>