tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: rw_lock_held



On Tue, Feb 06, 2018 at 07:06:33PM +0900, Ryota Ozaki wrote:
> Hi,
> 
> Is there any reason that rw_lock_held checks if it's held
> by *someone*, not by curlwp? It's confusable and most (or all?)
> users of the API seem to expect the latter (held by curlwp).
> 
> Well, rwlock.9 says that rw_*_held behave so, but that's perhaps
> just out-of-date because rw_read_held and rw_write_held check
> if it's held by curlwp.
> 
> So I think we should do either:
> (1) fix rw_lock_held, or
>     - probably it would be rw_read_held() || rw_write_held()
> (2) fix users of rw_lock_held.
>     - it also would replace rw_lock_held with
>       rw_read_held() || rw_write_held()
> 
> I prefer (1) because I think there is no user of the current
> behavior that is difficult to use for users (it may be useful
> as an internal utility function though).
> 
> Any thoughts?


your option (1) sounds fine to me.
a better wording for the manpage could be:

	Test the lock's condition and return non-zero if the lock is
	potentially held by the current LWP and matches the specified
	condition.  Otherwise, return zero.

thus if we see that lock is held (in write mode) by some other LWP then
we know that is not even potentially held by the current LWP.

-Chuck


Home | Main Index | Thread Index | Old Index