From owner-freebsd-hackers@freebsd.org Sun Apr 9 16:24:36 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 BA036D36EE5 for ; Sun, 9 Apr 2017 16:24:36 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 8278CA12 for ; Sun, 9 Apr 2017 16:24:36 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-io0-x232.google.com with SMTP id a103so6831390ioj.1 for ; Sun, 09 Apr 2017 09:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PGcYTtZ5TIDJ77DbPiJQ2wzZLs4147SEwUmNQEtEpzM=; b=ib1mlHiAngJi9ECbeWcxseHQhhgETA+HW0k7ppwTmoJ5scvlrgi7MxHwOpZWpoTtKV xoKSKQ9zBipwB3tibVxJVqW1AMiOtCU10kM5yys6gUTLFcQMbfyGUL1eIeDR5pKUSEOx FAc8ctSahadGIkwH7n3cKemmlc/WwR5TRNd15M4Q6VZtxqH5Tgi0JpWv+knmXEM5aLii caL8bbRSCB2bxxnEtnfwVRn8DJuxhpQk8MtOKuAbThrNrNbZgKvfznPqgT/MFx6NHoWJ uOzFdRKqB5srWA38wBxdUpVv+WNoQhOw/GV78MMT0uED8ASxQR7ra0uHRq/6rmujlmQO biFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PGcYTtZ5TIDJ77DbPiJQ2wzZLs4147SEwUmNQEtEpzM=; b=APPWrkHtkNfTsAekwckFbr+VrB/3w8Azv+ynqTAl6MtlPhqZe8k5e1e4CewifLgHlj eQP+xKIPfhefdgzH9JwTM0CY/rr4Yi++ELS2leeQydbf3YD+KSe763W+kE7744KmNfb6 Z1ofzRMcKSU9sedZaLwhvkNtpwaH0qaQAzZp8SH5ZD1G+OwzkK1vhaCFMtAMvGm74ZVR Hw/k7ii0sbHkPdELpIX4YJgt9xHPO0C8cIksYZ6Lsdy3K5vTOq2CDa+0tA+dFHo5IW85 5TnZVMOQfj+8L7VpUyC3iArPqwfWXPO5q0QCb6b2jyY5/gQWZXg+La95YyWPO/T2Lo8A C11Q== X-Gm-Message-State: AN3rC/7dwtgGfntc+Tq39E3vxQ21UF1KC6cHtx4ZXvEFDQt2Me7SaxxzZZ+S/CH7+jr2mK3OsGm1JDjwuozeuQ== X-Received: by 10.107.11.159 with SMTP id 31mr2397501iol.41.1491755075934; Sun, 09 Apr 2017 09:24:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.19.33 with HTTP; Sun, 9 Apr 2017 09:24:35 -0700 (PDT) In-Reply-To: References: From: Ryan Stone Date: Sun, 9 Apr 2017 12:24:35 -0400 Message-ID: Subject: Re: Understanding the FreeBSD locking mechanism To: 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:24:36 -0000 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. 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.