From owner-freebsd-hackers@freebsd.org Sun Apr 9 16:48:51 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA113D364CF for ; Sun, 9 Apr 2017 16:48:51 +0000 (UTC) (envelope-from vasanth.raonaik@gmail.com) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6507E3B0 for ; Sun, 9 Apr 2017 16:48:51 +0000 (UTC) (envelope-from vasanth.raonaik@gmail.com) Received: by mail-oi0-x22e.google.com with SMTP id b187so127163346oif.0 for ; Sun, 09 Apr 2017 09:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6Y0XDOknjJXK/q5/gAGI4h8hsW3WVLx4f39J0Vi01jg=; b=ZQCNiWGfb8lq2JU2qeQfiYvTcJnqiFmKbYQOIPNtyRVYFvvVR7xyn5+ezk1mdsxKpK A1X0wCzg1f/suT986BCqP0Z2qNI2dOj9GcDIYYjHucMCHKlOG3lNYfxj+sQwnGOsKlIu vB9AITCzxypu3lwAyNbCmsfNz3LNGrgoVt6BBD8eSiiaYKbf9FHM38XjhStb8CNYqXeJ mIANAcoCMAnHzenxobVW+ksk3nCXgEGazdbT2PU2L/ol7HNo/1qxXeCZwuaSHbURUTkM WwwKIxnAYBHTLWwM/dY/fXWHiq3RmDGLK9JEKZ7QO9vZLgp5ehWy+Wf+Q2Z9OSLHFz+6 mX+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6Y0XDOknjJXK/q5/gAGI4h8hsW3WVLx4f39J0Vi01jg=; b=FjEzEcynYdbnLxe7pN3OFRED8/By1vzZhN7FYpVcwOrncS9P3WVS/5z5tp0qk3QIfn ahgK5B1MzS/jVyJvG++ep7iiNn3GHrhoZMaUZsC8smlw0WYCGfzmEH1jP8Pe6ol+iE6h XRGSF7UtJWyqEltI9p0yzxBakoLrBs020F6h7/HJbCshSdUWLpMxZ/252lluWt+IO17w DBt8caQKoEII+PWyZmpUV9H1HVaSIZIIpBGTDm+LgLHfjjqOM1gVOK4NfjxKn/j5C9jV AjMA8hdHD0i/TaMCR5oslYGM7baJDi/EvnnKS1sty0SxD9ZOYXOHy1PNq+BGmNLbcLdl QHLw== X-Gm-Message-State: AN3rC/45zT5DtAjTfWZ8h3nroQl8uwzrdlUmyAzMzFeOwR/azlG149cEhuoLFSEERXgMGO0JinRc+NBfBe8gVA== X-Received: by 10.157.11.123 with SMTP id p56mr7577784otd.149.1491756530356; Sun, 09 Apr 2017 09:48:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: vasanth sabavat Date: Sun, 09 Apr 2017 16:48:39 +0000 Message-ID: Subject: Re: Understanding the FreeBSD locking mechanism To: Ryan Stone , Yubin Ruan Cc: Ed Schouten , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 16:48:51 -0000 On Sun, Apr 9, 2017 at 9:24 AM Ryan Stone wrote: > On Sun, Apr 9, 2017 at 6:13 AM, Yubin Ruan 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