Date: Wed, 14 Jun 2017 19:16:48 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Conrad Meyer <cem@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Re: A question about in lock usage in FreeBSD Message-ID: <20170614161648.GQ2088@kib.kiev.ua> In-Reply-To: <CAG6CVpVd-5_7cf5O=egC7cLisag9GCc_MN==EvS8M0i-Q8cS2Q@mail.gmail.com> References: <5940EA87.4030002@163.com> <CAG6CVpVd-5_7cf5O=egC7cLisag9GCc_MN==EvS8M0i-Q8cS2Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 14, 2017 at 08:45:21AM -0700, Conrad Meyer wrote:
> On Wed, Jun 14, 2017 at 12:49 AM, Jia-Ju Bai <baijiaju1990@163.com> wrote:
> > Namely, it is unsafe that the thread calls the function which may sleep when
> > the thread holds mutexes, reader/writer locks or read-mostly locks.
> > Is it right?
>
> Correct. sxlocks ("shared-exclusive," although I tend to think of the
> "s" as standing for "sleepable") can be held calling functions which
> may sleep.
Note that 'can' there refers only to the ability to make calls into the
locking subsystem without making it panic or triggering witness warnings.
The concrete sleepable locks itself might be unsuitable to held during
specific sleep, or cause some side effects if owned while sleeping that
make the system unusable.
For instance, we used to own vnode and buffer locks while filesystems
copied data in/out in the VOP_READ and VOP_WRITE. It was tolerated by
locking subsystem but was the source of large series of hard to tackle
deadlocks.
In other words, the permit to own the sleepable locks while sleeping is
only about an absence of the tiranic overseer who disallows that, and
not a guarantee that the permit is handy to use.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170614161648.GQ2088>