From owner-freebsd-arch@FreeBSD.ORG Thu Dec 22 18:28:43 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC919106564A; Thu, 22 Dec 2011 18:28:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A0B158FC0A; Thu, 22 Dec 2011 18:28:43 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 5616C46B06; Thu, 22 Dec 2011 13:28:43 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C30FDB962; Thu, 22 Dec 2011 13:28:42 -0500 (EST) From: John Baldwin To: "Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?=" Date: Thu, 22 Dec 2011 13:28:41 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <73233.1324389741@critter.freebsd.dk> <201112211028.26780.jhb@freebsd.org> <86zkeksftq.fsf@ds4.des.no> In-Reply-To: <86zkeksftq.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201112221328.41221.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 22 Dec 2011 13:28:42 -0500 (EST) Cc: Poul-Henning Kamp , freebsd-threads@freebsd.org, Niall Douglas , freebsd-arch@freebsd.org Subject: Re: [Patch] C1X threading support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 18:28:43 -0000 On Thursday, December 22, 2011 11:59:13 am Dag-Erling Sm=C3=B8rgrav wrote: > John Baldwin writes: > > Dag-Erling Sm=C3=B8rgrav writes: > > > Poul-Henning Kamp writes: > > > > mtx_unlock(l) > > > > { > > > > assert(l->id =3D=3D thread_id); > > > > l->id =3D NULL; > > > > atomic_magic_unlock(l->lock_field) > > > > } > > > susceptible to race conditions > > How so? >=20 > I should have specified "if called from a thread that does not own the > mutex" You can do the same check as mtx_assert_held() internally and fail the unlo= ck=20 request in that case (or abort or what have you). > > > > mtx_assert_held(l) > > > > { > > > > assert(l->lock-field !=3D 0); > > > > assert(l->id =3D=3D thread_id); > > > > } > > > susceptible to race conditions > > How so? >=20 > I was going to point out that the state of the mutex can change between > the two asserts, but as you say, at least one of them is guaranteed to > fail... *if* you assume that these fields can be read atomically, which > was one of my objections. I do think these have to be atomic. I think lock-field must be able to be= =20 atomically read by definition. I think it is not an unreasonable requireme= nt=20 to have the implementation implement a thread_id that fits in an atomic typ= e=20 if it is not able to encode the thread_id into the lock cookie itself. I do think if l->id was not atomic it might be feasible to see a value while the thread is not locked that is equivalent to the current thread's ID based on observing different parts of l->id from different writes. There might b= e=20 ways the implementation could guard against that however. In practice thou= gh=20 I think pointers are atomic with regards to loads and stores on nearly all= =20 machines. =2D-=20 John Baldwin