Date: Sun, 09 Apr 2017 16:48:39 +0000 From: vasanth sabavat <vasanth.raonaik@gmail.com> To: Ryan Stone <rysto32@gmail.com>, Yubin Ruan <ablacktshirt@gmail.com> Cc: Ed Schouten <ed@nuxi.nl>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Understanding the FreeBSD locking mechanism Message-ID: <CAAuizBiJFkqaEcaHkjP7ZVTgALzVagOopaf9gt3JjbQA3UE02A@mail.gmail.com> In-Reply-To: <CAFMmRNwWnaq-4vEDCByqdUzWfoiZeN0nM_M5rt8ST0P8xnUTsA@mail.gmail.com> References: <e99b6366-7d30-a889-b7db-4a3b3133ff5e@gmail.com> <CABh_MKkbVVi%2BgTkaBVDvVfRggS6pbHKJE_VbYBZpAaTCZ81b7Q@mail.gmail.com> <c72c0ee3-328d-3efc-e8a0-4d6c0d5c8cee@gmail.com> <CAFMmRNwWnaq-4vEDCByqdUzWfoiZeN0nM_M5rt8ST0P8xnUTsA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 9, 2017 at 9:24 AM Ryan Stone <rysto32@gmail.com> wrote: > On Sun, Apr 9, 2017 at 6:13 AM, Yubin Ruan <ablacktshirt@gmail.com> wrote: > > > > > #######1, spinlock used in an interrupt handler > > If a thread A holding a spinlock T get interrupted and the interrupt > > handler responsible for this interrupt try to acquire T, then we have > > deadlock, because A would never have a chance to run before the > > interrupt handler return, and the interrupt handler, unfortunately, > > will continue to spin ... so in this situation, one has to disable > > interrupt before spinning. > > > > As far as I know, in Linux, they provide two kinds of spinlocks: > > > > spin_lock(..); /* spinlock that does not disable interrupts */ > > spin_lock_irqsave(...); /* spinlock that disable local interrupt * > > > In the FreeBSD locking style, a spinlock is only used in the case where one > needs to > synchronize with an interrupt handler. This is why spinlocks always > disable local > interrupts in FreeBSD. Isn't it true that interrupt handlers instead of running on the current thread stack now have their own thread? > > FreeBSD's lock for the first case is the MTX_DEF mutex, which is > adaptively-spinning > blocking mutex implementation. In short, the MTX_DEF mutex will spin > waiting for the > lock if the owner is running, but will block if the owner is deschedules. > This prevents > expensive trips through the scheduler for the common case where the mutex > is only held > for short periods, without wasting CPU cycles spinning in cases where the > owner thread is > descheduled and therefore will not be completing soon. > > #######2, priority inversion problem > > If thread B with a higher priority get in and try to acquire the lock > > that thread A currently holds, then thread B would spin, while at the > > same time thread A has no chance to run because it has lower priority, > > thus not being able to release the lock. > > (I haven't investigate enough into the source code, so I don't know > > how FreeBSD and Linux handle this priority inversion problem. Maybe > > they use priority inheritance or random boosting?) > > > > FreeBSD's spin locks prevent priority inversion by preventing the holder > thread from > being descheduled. > > MTX_DEF locks implement priority inheritance. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Thanks, Vasanth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAAuizBiJFkqaEcaHkjP7ZVTgALzVagOopaf9gt3JjbQA3UE02A>