Re: Debugging function of localcount

[Paul Goyette <paul%whooppee.com@localhost>]

On Tue, 14 Nov 2017, Taylor R Campbell wrote:

> > Date: Mon, 13 Nov 2017 13:59:32 +0900
> > From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
> >
> > I'm sorry for not replying this thread. I'm back.
> >
> > I've revised the patch as your suggestions:
> >   http://www.netbsd.org/~ozaki-r/localcount_debug_atomic.revised.diff
>
> Looks better, thanks!
>
> Couple nits:
>
> 1. Still need to volatile-qualify lc_refcnt.
> 2. Either use unsigned and atomic_cas_uint, or uint32_t and
>   atomic_cas_32, but not a mixture.
>
> Random thought: What about a per-LWP counter for diagnostics, with
> lwp_getspecific/setspecific?  No interprocessor overhead that way.
> Could even assert when an lwp exits, or when a softint returns, that
> no localcounts were leaked.
>
> (This slightly changes the semantics of localcount so that it cannot
> be passed from lwp to lwp (i.e., can't acquire in one and release in
> the other; must acquire in both and release in both), but I don't
> really see a problem with that.)

It seems to me that there's really no good reason to prohibit migration 
from one lwp to another;  the only apparent benefit of having such a 
restriction is the ability to verify that the restriction isn't being 
violated.

If we're changing the semantics to disallow this, we should be sure to 
update the man-page, too.  (Actually, we should update the man page in 
any case, to document whether such migration between lwp's is permitted 
or disallowed.)


+------------------+--------------------------+----------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:          |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+------------------+--------------------------+----------------------------+