From owner-freebsd-current@freebsd.org Fri Nov 6 12:21:48 2015 Return-Path: Delivered-To: freebsd-current@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 0BC0DA27962 for ; Fri, 6 Nov 2015 12:21:48 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D0E851D11; Fri, 6 Nov 2015 12:21:47 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.130] ([69.198.134.97]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id tA6CLblQ024475 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2015 12:21:39 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host [69.198.134.97] claimed to be [192.168.1.130] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [PATCH] microoptimize by trying to avoid locking a locked mutex From: David Chisnall In-Reply-To: <20151106005524.GA4877@dft-labs.eu> Date: Fri, 6 Nov 2015 04:21:37 -0800 Cc: Ian Lepore , John Baldwin , Adrian Chadd , freebsd-current , Konstantin Belousov Content-Transfer-Encoding: quoted-printable Message-Id: <5972A132-1589-4230-A3B4-74D2FD442331@FreeBSD.org> References: <20151104233218.GA27709@dft-labs.eu> <20151105192623.GB27709@dft-labs.eu> <1563180.x0Z3Ou4xid@ralph.baldwin.cx> <1446766522.91534.412.camel@freebsd.org> <20151106005524.GA4877@dft-labs.eu> To: Mateusz Guzik X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 12:21:48 -0000 On 5 Nov 2015, at 16:55, Mateusz Guzik wrote: >=20 >> Will that cause problems, especially for code inside a loop >> where the compiler may decide to shuffle things around? >>=20 >=20 > Lock value is volatile, so the compiler should not screw us up. Note: volatile means do not reorder loads/stores *to this value*, the = compiler is completely free to reorder loads/stores to other values = around this one. _Atomic exists in C11 to do the right thing when you = want to enforce stricter barriers. In this case, we=E2=80=99re = currently relying on the compiler not being able to see through the = assembly. At some point in the future, I imagine that we=E2=80=99ll move to using = C11 atomic operations, which will allow the compiler more freedom. The = new reads that you=E2=80=99re currently doing should be replaced by = explicit atomic reads with a relaxed memory order (to enforce atomicity = with respect to that variable). If we were to replace the mtx_lock = field with an _Atomic variant, then the current code would make it a = sequentially consistent read, which would add a lot of extra overhead. = Note also that it is undefined behaviour in C11 to do atomic and = non-atomic accesses to the same underlying memory location. Please = consider the future maintainability of the code when making this change. David