Messages in this thread | | | Date | Mon, 1 Dec 2014 13:31:29 -0800 | Subject | Re: POSIX mutex destruction requirements vs. futexes | From | Linus Torvalds <> |
| |
On Mon, Dec 1, 2014 at 12:44 PM, Torvald Riegel <triegel@redhat.com> wrote: > > User space could introduce a wrapper (e.g., glibc could provide a futex > wrapper that allows spurious wakeup on return of 0) -- but glibc can't > prevent users from not using futexes directly and not through the > wrapper. Or should it try to intercept direct, non-wrapper uses of the > futex syscall in some way?
So I don't think we even need to worry about direct users of the futex system call. They had better know what they are doing.
> I agree, and that's why I mentioned that it may seem odd to fix this on > the level of the kernel interface. However, it just seems the best > approach when considering practice in kernel and user space, the > by-design futex properties, and the realities of what POSIX requires.
Sure. That said, I think there really are very few cases we need to worry about:
- the ptreads_mutex implementation itself.
This is, after all, what 99% of all applications will use. And here, the only worry is to make sure that glibc (or whatever other libc) is aware of its own reuse of allocations, and basically know that it can get into the situation where a reused mutex memory allocation can effectively see "stale" wakeups. That is, of course, assuming that the library implementation is the expected racy one. There *are* ways to avoid the races, although they are generally not really even worth the bother - just calling futex_wait() in a loop is the RightThing(tm) to do.
- other random direct futex users
Quite frankly, these are few. There are valid and real use cases (the CLONE_CHILD_CLEARTID interface, for example, expects the user to use a raw futex), but they tend to be low-level enough that they'd really better know about this. And again, it should be easy enough to just loop around FUTEX_WAIT and just reading the value if somebody is worried about this.
Making the documentation talk about the issue, and making the strong suggestion to make any FUTEX_WAIT style use just always loop and check the actual value for simplicity and robustness is probably the right approach.
Linus
| |