From owner-freebsd-arch@FreeBSD.ORG Mon Oct 27 16:29:24 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CBCEEBF for ; Mon, 27 Oct 2014 16:29:24 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65A52E85 for ; Mon, 27 Oct 2014 16:29:24 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 66B24B96E; Mon, 27 Oct 2014 12:29:23 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: RfC: fueword(9) and casueword(9) Date: Mon, 27 Oct 2014 11:17:51 -0400 Message-ID: <2048849.GkvWliFbyg@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-PRERELEASE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20141021162306.GE1877@kib.kiev.ua> References: <20141021094539.GA1877@kib.kiev.ua> <20141022002825.H2080@besplex.bde.org> <20141021162306.GE1877@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 27 Oct 2014 12:29:23 -0400 (EDT) Cc: Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 16:29:24 -0000 On Tuesday, October 21, 2014 07:23:06 PM Konstantin Belousov wrote: > On Wed, Oct 22, 2014 at 01:41:12AM +1100, Bruce Evans wrote: > > A new API should try to fix these __DEVOLATILE() abominations. I think it > > is safe, and even correct, to declare the pointers as volatile const void > > *, since the functions really can handle volatile data, unlike copyin(). > > > > Atomic op functions are declared as taking pointers to volatile for > > similar reasons. Often they are applied to non-volatile data, but > > adding a qualifier is type-safe and doesn't cost efficiency since the > > pointer access is is not known to the compiler. (The last point is not > > so clear -- the compiler can see things in the functions since they are > > inline asm. fueword() isn't inline so its (in)efficiency is not changed.) > > > > The atomic read functions are not declared as taking pointers to const. > > The __DECONST() abomination might be used to work around this bug. > > I prefer to not complicate the fetch(9) KPI due to the mistakes in the > umtx structures definitions. I think that it is bug to mark the lock > words with volatile. I want the fueword(9) interface to be as much > similar to fuword(9), in particular, volatile seems to be not needed. I agree with Bruce here. casuword() already accepts volatile. I also think umtx is correct in marking the field as volatile. They are subject to change without the compiler's knowledge albeit by other threads rather than signal handlers. Having them marked volatile doesn't really matter for the kernel, but the header is also used in userland and is relevant in sem_new.c, etc. -- John Baldwin