From owner-svn-src-head@FreeBSD.ORG Sat Jun 15 23:23:13 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AE6149C8; Sat, 15 Jun 2013 23:23:13 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 79EFF1D46; Sat, 15 Jun 2013 23:23:12 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id C94DA18A; Sun, 16 Jun 2013 01:18:38 +0200 (CEST) Date: Sun, 16 Jun 2013 01:23:14 +0200 From: Pawel Jakub Dawidek To: Ed Schouten Subject: Re: svn commit: r251796 - head/sbin/hastd Message-ID: <20130615232314.GB1403@garage.freebsd.pl> References: <201306152218.r5FMI0uT047135@svn.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6" Content-Disposition: inline In-Reply-To: <201306152218.r5FMI0uT047135@svn.freebsd.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 23:23:13 -0000 --ZoaI/ZTpAVc4A5k6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 15, 2013 at 10:18:00PM +0000, Ed Schouten wrote: > Author: ed > Date: Sat Jun 15 22:17:59 2013 > New Revision: 251796 > URL: http://svnweb.freebsd.org/changeset/base/251796 >=20 > Log: > Let hastd use C11 atomics. > =20 > C11 atomics now work on all the architectures. Have at least a single > piece of software in our base system that uses C11 atomics. This > somewhat makes it less likely that we break it because of LLVM imports, > etc. Hmm, I don't like HAST to be a victim of bad LLVM import. This is not the kind of software you run on HEAD (so it might go unnoticed initially) and this is the kind of software that when breaks can have serious consequences. What kind of breaks are we talking about? That HAST will stop compiling or HAST can start corrupting data? > Modified: > head/sbin/hastd/refcnt.h >=20 > Modified: head/sbin/hastd/refcnt.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/sbin/hastd/refcnt.h Sat Jun 15 21:29:47 2013 (r251795) > +++ head/sbin/hastd/refcnt.h Sat Jun 15 22:17:59 2013 (r251796) > @@ -32,24 +32,24 @@ > #ifndef __REFCNT_H__ > #define __REFCNT_H__ > =20 > -#include > +#include > =20 > #include "pjdlog.h" > =20 > -typedef unsigned int refcnt_t; > +typedef atomic_uint refcnt_t; > =20 > static __inline void > refcnt_init(refcnt_t *count, unsigned int v) > { > =20 > - *count =3D v; > + atomic_init(count, v); > } > =20 > static __inline void > refcnt_acquire(refcnt_t *count) > { > =20 > - atomic_add_acq_int(count, 1); > + atomic_fetch_add_explicit(count, 1, memory_order_acquire); > } > =20 > static __inline unsigned int > @@ -58,7 +58,7 @@ refcnt_release(refcnt_t *count) > unsigned int old; > =20 > /* XXX: Should this have a rel membar? */ > - old =3D atomic_fetchadd_int(count, -1); > + old =3D atomic_fetch_sub(count, 1); > PJDLOG_ASSERT(old > 0); > return (old - 1); > } --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --ZoaI/ZTpAVc4A5k6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlG892IACgkQForvXbEpPzRVFwCgoCrmJ5/fMDqmpfV7gUQ1SByP TvkAnjJlmiAjQ9d+y7hUxr+R6678dbS6 =XzNh -----END PGP SIGNATURE----- --ZoaI/ZTpAVc4A5k6--