Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934159AbbLPPlB (ORCPT ); Wed, 16 Dec 2015 10:41:01 -0500 Received: from mail-wm0-f48.google.com ([74.125.82.48]:35369 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752442AbbLPPk7 (ORCPT ); Wed, 16 Dec 2015 10:40:59 -0500 Message-ID: <56718607.2080600@gmail.com> Date: Wed, 16 Dec 2015 16:40:55 +0100 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Davidlohr Bueso CC: mtk.manpages@gmail.com, Thomas Gleixner , Darren Hart , Torvald Riegel , lkml , libc-alpha , linux-man , "Carlos O'Donell" , Roland McGrath , Jakub Jelinek , Ingo Molnar , bill o gallmeister , bert hubert , Jan Kiszka , Eric Dumazet , Arnd Bergmann , Rusty Russell , Heinrich Schuchardt , Andy Lutomirski , Daniel Wagner , Anton Blanchard , Steven Rostedt , Rich Felker , Jonathan Wakely , Mike Frysinger , Peter Zijlstra Subject: Re: futex(3) man page, final draft for pre-release review References: <56701916.4090203@gmail.com> <20151215224119.GA28877@linux-uzut.site> In-Reply-To: <20151215224119.GA28877@linux-uzut.site> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2709 Lines: 71 Hi David, On 12/15/2015 11:41 PM, Davidlohr Bueso wrote: > On Tue, 15 Dec 2015, Michael Kerrisk (man-pages) wrote: > >> When executing a futex operation that requests to block a thread, >> the kernel will block only if the futex word has the value that >> the calling thread supplied (as one of the arguments of the >> futex() call) as the expected value of the futex word. The load??? >> ing of the futex word's value, the comparison of that value with >> the expected value, and the actual blocking will happen atomi??? >> >> FIXME: for next line, it would be good to have an explanation of >> "totally ordered" somewhere around here. >> >> cally and totally ordered with respect to concurrently executing >> futex operations on the same futex word. > > So there are two things here regarding ordering. One is the most obvious > which is ordered due to the taking/dropping the hb spinlock. Secondly, its > the cases which Peter brought up a while ago that involves atomic futex ops > futex_atomic_*(), which do not have clearly defined semantics, and you get > inconsistencies with certain archs (tile being the worst iirc). > > But anyway, the important thing users need to know about is that the atomic > futex operation must be totally ordered wrt any other user tasks that are trying > to access that address. This is not necessarily the case for kernel ops. Peter > illustrates this nicely with lock stealing example; > (see https://lkml.org/lkml/2015/8/26/596). Thanks. I reworded things here a little. > Internally, I believe we decided that making it fully ordered (as opposed to > making use of implicit barriers for ACQUIRE/RELEASE), so you'd endup having > an MB ll/sc MB kind of setup. > > [...] > >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> #define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \ >> } while (0) > > Nit, but for this we have err(3). I don't much like them though (not in POSIX). Thanks for the help David. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/