Date: Tue, 12 Feb 2013 12:14:21 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Ian Lepore <ian@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Jilles Tjoelker <jilles@stack.nl> Subject: Re: Request for review, time_pps_fetch() enhancement Message-ID: <CAJ-VmonL%2BvL9=Ou1O5FzX7xLg5hJ%2BAuCRiSVQZ7cXH8%2BBjYtbQ@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonL%2BvL9=Ou1O5FzX7xLg5hJ%2BAuCRiSVQZ7cXH8%2BBjYtbQ>