From owner-freebsd-hackers@FreeBSD.ORG  Tue Feb 12 20:14:23 2013
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
 by hub.freebsd.org (Postfix) with ESMTP id 16FCE505;
 Tue, 12 Feb 2013 20:14:23 +0000 (UTC)
 (envelope-from adrian.chadd@gmail.com)
Received: from mail-we0-x231.google.com (we-in-x0231.1e100.net
 [IPv6:2a00:1450:400c:c03::231])
 by mx1.freebsd.org (Postfix) with ESMTP id 6FD01E87;
 Tue, 12 Feb 2013 20:14:22 +0000 (UTC)
Received: by mail-we0-f177.google.com with SMTP id d7so407546wer.22
 for <multiple recipients>; Tue, 12 Feb 2013 12:14:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:x-received:sender:in-reply-to:references:date
 :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
 bh=HzlO/boktjRK1MP4rSb0ybjAuOMjOFOqDVRt/Rw1L+A=;
 b=YBnQx0kQKeVbaKngl9A4u+g+I3sLCotQ+lhqyt0+6aD3heF6hZu8/0vVE2d2R2+4aD
 +XS8aMYCpklIFGX7ZQYopjJ410xY4pJAgbv/Po9ptMQ0xCkcXPZczIkaXiovf/LC667l
 G+krBHuEiMA2qWq9zyZqmNV4y2Prcb9x1D3lH1hHgVrQXWVUKfHR9UN40vyjnWEUnorX
 QuQFGk8jRhclRQFWnzKXLO8RcUlDo9Dvo0Ww2abbePh7J0aRefTwU+u41hiNOl5BVHGS
 UjtSqGKirD3M9XMZk0C38RrlnvCrbvOORb5iKYIj2ZVVwDMu35F8HvJKDwoVGddSGY1p
 TOFg==
MIME-Version: 1.0
X-Received: by 10.180.93.234 with SMTP id cx10mr5669204wib.34.1360700061637;
 Tue, 12 Feb 2013 12:14:21 -0800 (PST)
Sender: adrian.chadd@gmail.com
Received: by 10.216.236.88 with HTTP; Tue, 12 Feb 2013 12:14:21 -0800 (PST)
In-Reply-To: <1360685019.4545.170.camel@revolution.hippie.lan>
References: <1360125698.93359.566.camel@revolution.hippie.lan>
 <20130206155830.GX2522@kib.kiev.ua>
 <20130209134706.GB19909@stack.nl>
 <20130210103745.GI2522@kib.kiev.ua>
 <1360685019.4545.170.camel@revolution.hippie.lan>
Date: Tue, 12 Feb 2013 12:14:21 -0800
X-Google-Sender-Auth: g8lUSZPZEP3c6j130s-jaS_Dkl4
Message-ID: <CAJ-VmonL+vL9=Ou1O5FzX7xLg5hJ+AuCRiSVQZ7cXH8+BjYtbQ@mail.gmail.com>
Subject: Re: Request for review, time_pps_fetch() enhancement
From: Adrian Chadd <adrian@freebsd.org>
To: Ian Lepore <ian@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Konstantin Belousov <kostikbel@gmail.com>,
 "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>,
 Jilles Tjoelker <jilles@stack.nl>
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Feb 2013 20:14:23 -0000

On 12 February 2013 08:03, Ian Lepore <ian@freebsd.org> wrote:

>> I agree that for practical means, the _currently_ used compilers should
>> consider the tsleep() call as the sequential point. But then the volatile
>> qualifier cast applied for the given access would not change the code as
>> well.
>>
>
> Doesn't this then imply that essentially every driver has this problem,
> and for that matter, every sequence of code anywhere in the base
> involving "loop while repeatedly sleeping, then waking and checking the
> state of some data for changes"?  I sure haven't seen that many volatile
> qualifiers scattered around the code.

Well, not even that - any cached access (eg to a softc member) after a
mutex operation would be invalid.

Hence why there's supposed to be some specific fairy dust sprinkled
over those functions/inlines to tell the compiler to invalidate local
copies of memory structures.



Adrian