From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 03:24:34 2010 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 1A09B106566C; Fri, 17 Sep 2010 03:24:34 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mx1.freebsd.org (Postfix) with ESMTP id B3BF48FC1A; Fri, 17 Sep 2010 03:24:33 +0000 (UTC) X-AuditID: 12074424-b7b2bae000005b3f-87-4c92df56e785 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 23.BA.23359.65FD29C4; Thu, 16 Sep 2010 23:24:06 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id o8H3OWJk009314; Thu, 16 Sep 2010 23:24:32 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o8H3OUor018959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Sep 2010 23:24:32 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id o8H3OThN013379; Thu, 16 Sep 2010 23:24:29 -0400 (EDT) Date: Thu, 16 Sep 2010 23:24:29 -0400 (EDT) From: Benjamin Kaduk To: John Baldwin In-Reply-To: <201009161416.05759.jhb@freebsd.org> Message-ID: References: <20100915134415.GA23727@pm513-1.comsys.ntu-kpi.kiev.ua> <20100916173307.GA1994@pm513-1.comsys.ntu-kpi.kiev.ua> <201009161416.05759.jhb@freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: AAAAAA== Cc: freebsd-hackers@freebsd.org Subject: Re: Questions about mutex implementation in kern/kern_mutex.c 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: Fri, 17 Sep 2010 03:24:34 -0000 On Thu, 16 Sep 2010, John Baldwin wrote: > On Thursday, September 16, 2010 1:33:07 pm Andrey Simonenko wrote: > >> The mtx_owned(9) macro uses this property, mtx_owned() does not use anything >> special to compare the value of m->mtx_lock (volatile) with current thread >> pointer, all other functions that update m->mtx_lock of unowned mutex use >> compare-and-set instruction. Also I cannot find anything special in >> generated Assembler code for volatile variables (except for ia64 where >> acquire loads and release stores are used). > > No, mtx_owned() is just not harmed by the races it loses. You can certainly > read a stale value of mtx_lock in mtx_owned() if some other thread owns the > lock or has just released the lock. However, we don't care, because in both > of those cases, mtx_owned() returns false. What does matter is that > mtx_owned() can only return true if we currently hold the mutex. This works > because 1) the same thread cannot call mtx_unlock() and mtx_owned() at the > same time, and 2) even CPUs that hold writes in store buffers will snoop their > store buffer for local reads on that CPU. That is, a given CPU will never > read a stale value of a memory word that is "older" than a write it has > performed to that word. Sorry for the naive question, but would you mind expounding a bit on what keeps the thread from migrating to a different CPU and getting a stale value there? (I can imagine a couple possible mechanisms, but don't know enough to know which one(s) are the real ones.) Thanks, Ben Kaduk