On Thu, Aug 20, 2015 at 12:40:46AM +0200, Thomas Gleixner wrote: > On Wed, 5 Aug 2015, Darren Hart wrote: > > On Mon, Jul 27, 2015 at 02:07:15PM +0200, Michael Kerrisk (man-pages) wrote: > > > .\" FIXME XXX ===== Start of adapted Hart/Guniguntala text ===== > > > .\" The following text is drawn from the Hart/Guniguntala paper > > > .\" (listed in SEE ALSO), but I have reworded some pieces > > > .\" significantly. Please check it. > > > > > > The PI futex operations described below differ from the other > > > futex operations in that they impose policy on the use of the > > > value of the futex word: > > > > > > * If the lock is not acquired, the futex word's value shall be > > > 0. > > > > > > * If the lock is acquired, the futex word's value shall be the > > > thread ID (TID; see gettid(2)) of the owning thread. > > > > > > * If the lock is owned and there are threads contending for the > > > lock, then the FUTEX_WAITERS bit shall be set in the futex > > > word's value; in other words, this value is: > > > > > > FUTEX_WAITERS | TID > > > > > > > > > Note that a PI futex word never just has the value FUTEX_WAITERS, > > > which is a permissible state for non-PI futexes. > > > > The second clause is inappropriate. I don't know if that was yours or > > mine, but non-PI futexes do not have a kernel defined value policy, so > > ==FUTEX_WAITERS cannot be a "permissible state" as any value is > > permissible for non-PI futexes, and none have a kernel defined state. > > Depends. If the regular futex is configured as robust, then we have a > kernel defined value policy as well. Indeed, thanks for catching that. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
