Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Jun 2017 15:49:27 +0800
From:      Jia-Ju Bai <baijiaju1990@163.com>
To:        kostikbel@gmail.com
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Re: A question about in lock usage in FreeBSD
Message-ID:  <5940EA87.4030002@163.com>

next in thread | raw e-mail | index | archive | help
>  On Wed, Jun 14, 2017 at 09:10:29AM +0800, Jia-Ju Bai wrote:
>  >/  Hi,
/>  >/
/>  >/  I am a freshman in developing FreeBSD drivers, and I have a question in
/>  >/  lock usage in FreeBSD.
/>  >/
/>  >/  The kernel provides some kinds of locks in developing drivers, such as
/>  >/  "mutex lock", "mutex spin lock", "rw lock" and "sx lock". I want to know
/>  >/  which locks should be held when the thread can sleep.
/>  Replace should with can in the question.

>  >/    From my knowledge of FreeBSD document, I make the following points:
/>  >/  (1) "rw lock" and "sx lock" can be used in this situation;
/>  You cannot own rw lock while trying to sleep.

>  >/  (2) "mutex lock" and "mutex spin lock" are forbidden in this situation.
/>  >/
/>  >/  If my points are right, I will make another point:
/>  >/  mutex_lock will let the thread sleep when the lock is requested, so the
/>  >/  mutex_lock can not be called in nested style (namely it is unsafe that
/>  >/  mutex_lock is called again when a "mutex lock" is held).
/>  No, mutex does not put the thread which cannot obtain the lock immediately,
>  to sleep.  The thread is blocked on turnstile.
>
>  >/
/>  >/  Are my points are right?
/>  >/  I am looking forward to useful opinions and answers :)
/>  Read locking(9).


Thank you very much, your reply is very helpful to me :)
According to your advice, I think I get the answer from locking(9).
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?

Thanks,
Jia-Ju Bai




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