Date: Mon, 29 Oct 2012 08:53:07 +0100 From: Andre Oppermann <andre@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, Jeff Roberson <jeff@freebsd.org>, attilio@freebsd.org, Florian Smeets <flo@freebsd.org>, Bruce Evans <bde@freebsd.org>, svn-src-projects@freebsd.org Subject: Re: svn commit: r238907 - projects/calloutng/sys/kern Message-ID: <508E35E3.9020801@freebsd.org> In-Reply-To: <CAJ-VmonMQgT7rGOhZ-hq%2B3R%2BSbdNfTBNHLAWW1xwicHy1cb2BQ@mail.gmail.com> References: <201207301350.q6UDobCI099069@svn.freebsd.org> <CAJ-FndBj8tpC_BJXs_RH8sG2TBG8yA=Lxu3-GTVT9Ap_zOCuVQ@mail.gmail.com> <CAJ-FndDnO7wjnWPV0tTu%2BUGHjsxa3YDarMxmyei3ZmjLAFvRkQ@mail.gmail.com> <201207301732.33474.jhb@freebsd.org> <CAJ-FndD5EO12xsWOAe6u0EvX00q33wxO4OivnGjzj0=T2Oe8uA@mail.gmail.com> <CAJ-FndCRg0UCThFkatp=tw7rUWWCvhsApLE=iztLpxpGBC1F9w@mail.gmail.com> <CAJ-FndBqV2uD8Th9ePtxyJwhMAPzY3AXA5cQ7HszLp=%2BfSpHTA@mail.gmail.com> <CAJ-FndDPLmkpAJeGVN2wgbhdgHYezyUV-PPvH9e-CA7Go7HG3A@mail.gmail.com> <CAJ-VmonMQgT7rGOhZ-hq%2B3R%2BSbdNfTBNHLAWW1xwicHy1cb2BQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29.10.2012 03:25, Adrian Chadd wrote: > So colour me a bit silly, but why didn't you use an atomic here for > that single variable, rather than a memory barrier alone? Because sched_pin() can only be used within a critical section and thus guarantees that we stay on the same CPU. So we don't have to worry about full SMP visibility and preventing just the compiler from reordering or register caching the value. The atomic functions do a full bus lock cycle and a CPU pipeline flush (in most cases) to make sure that the new value is seen on all CPU's at the same time. On SMP architectures and shared data structures you have to worry about three things: - compiler reordering (instruction optimizations) - cpu pipelines - memory and cache coherency To be honest it takes some time to understand the different behaviors and then to be able to reason about it. There is quite some nice and dense literature out there about atomics. Googling turns up the important ones. > I feel slightly nitpicky about it, but this stuff rubs me up slightly > the wrong way, same as the "don't worry about using atomics for 32 bit > set/reads, as those are guaranteed to be atomic on all of the > platforms we use" done what, last year or so. Well, we have to have a baseline somewhere. Many architectures don't even have atomics for less than 32 bits. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?508E35E3.9020801>