From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 17 20:52:10 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C53E6106564A for ; Sun, 17 Apr 2011 20:52:10 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7F7838FC18 for ; Sun, 17 Apr 2011 20:52:10 +0000 (UTC) Received: by gxk28 with SMTP id 28so1991791gxk.13 for ; Sun, 17 Apr 2011 13:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3GOBVwEaPQTOzzxu57f41FATGqIpWKPY0bDintYTi3o=; b=kPENSthUkxgSOiPbDtw2H/wKqBdTO1AQoTOxQB4Y5/OCo8sedaMtWgJKqi0tMf5WA3 RmsszoMwiIfkNye8x5ktwxXveRos5lQ1WgraBghaShlPLoWgcNO0LvonZCp4ZV2nVyrf hYmkoa299uY3zHGZhr72RKtKlVAe2Q1W3gMr4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ogvAfdAJqAnQx8LIRVTtrv7jzUIfcQWgt026OFOFTOtyOp0clUfgPnlyWzo3HVBfwz pKviyDK8ie2B5cNzga0bnxLMrLSkjb60wUoE9KO+wlsOskBWXJUQ8nqILKb4Ww5Ia1Nu 8G5vW+rAAhUYEOcCeo3S5E/iwxOu3aRWJgHpE= MIME-Version: 1.0 Received: by 10.236.76.161 with SMTP id b21mr2914736yhe.222.1303071764189; Sun, 17 Apr 2011 13:22:44 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.103.131 with HTTP; Sun, 17 Apr 2011 13:22:44 -0700 (PDT) In-Reply-To: <397135152.167477.1303069788579.JavaMail.root@erie.cs.uoguelph.ca> References: <397135152.167477.1303069788579.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 17 Apr 2011 22:22:44 +0200 X-Google-Sender-Auth: UktoYauQTiw8XO7uQg-FsJeeyPg Message-ID: From: Attilio Rao To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 20:52:10 -0000 2011/4/17 Rick Macklem : > Hi, > > I should know the answer to this, but... When reading a global kernel > variable, where its modifications are protected by a mutex, is it > necessary to get the mutex lock to just read its value? > > For example: > A =C2=A0 =C2=A0if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) !=3D 0) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return (EPERM); > versus > B =C2=A0 =C2=A0MNT_ILOCK(mp); > =C2=A0 =C2=A0 if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) !=3D 0) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MNT_IUNLOCK(mp); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return (EPERM); > =C2=A0 =C2=A0 } > =C2=A0 =C2=A0 MNT_IUNLOCK(mp); > > My hunch is that B is necessary if you need an up-to-date value > for the variable (mp->mnt_kern_flag in this case). > > Is that correct? > > Thanks in advance for help with this, rick In general, FreeBSD kernel assumes that read and writes of the word boundry and of the int types are always atomic. Considering this, if a kernel variable is of int type or word boundry size you don't strictly need a lock there. Anyway, locking also bring some side effect, like usage of memory and compiler barriers... while it is true that bounded read/writes should be seq points, it is not too obvious to predict if the barrier is necessary or not, is implied or not in every architecture we support. Said that, for a matter of consistency and of better semantic, I prefer to also lock "simple" read/writes when the objects are explicitly equipped to do that. Attilio --=20 Peace can only be achieved by understanding - A. Einstein