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 <stdio.h> >> #include <errno.h> >> #include <stdlib.h> >> #include <unistd.h> >> #include <sys/wait.h> >> #include <sys/mman.h> >> #include <sys/syscall.h> >> #include <linux/futex.h> >> #include <sys/time.h> >> >> #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-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
