Messages in this thread | | | Date | Tue, 17 Nov 2009 21:40:55 -0800 | From | Darren Hart <> | Subject | Re: [PATCH] futex: add FUTEX_SET_WAIT operation |
| |
Michel Lespinasse wrote:
> One difficulty with adaptive spinning is that we want to avoid deadlocks. > If two threads end up spinning in-kernel waiting for each other, we better > have preemption enabled... or detect and deal with the situation somehow.
This is really only a problem for SCHED_FIFO tasks right? (SCHED_OTHER should get scheduled() out when CFS deems they've exhausted their fair share). Real-Time tasks typically should be using PI anyway as adaptive locking is non-deterministic and doesn't provide for PI. So I'm not sure how critical this problem is in practice.
> Also one aspect I dislike is that this would impose a given format on the > futex for storing the TID.
We do have a precedent for this with robust as well as PI futexes.
I would prefer if there were several bits available > in the futex for userspace to do whatever they want. 8 bits would likely > be enough, which leaves 24 for the TID - enough for us, but I have no idea > if that's good enough for upstream inclusion. It that's not possible, > one possible compromise could be:
And we already use two of those bits for OWNER_DIED and FUTEX_WAITERS. Perhaps you just have to choose between your own value scheme and adaptive spinning (sounds horribly limiting as I'm typing this...).
> > - userspace passes a TID (which it extracted from the futex value; but kernel > does not necessarily know how) > - kernel spins until that TID goes to sleep, or the futex value is not equal > to val or setval anymore > - if val != setval and the futex value is val, set it to setval > - if the futex valus is setval, block, otherwise -EWOULDBLOCK. > > If the lock got stolen from a different thread, userspace can decide to > retry with or without adaptive spinning.
I'll think on this a bit more...
> > That would be the most generic interface I can think of, though it's > starting to be a LOT of parameters - actually, too many to pass through > the _syscall6 interface. > > > I also like Darren's suggestion to do a FUTEX_SET_WAIT_REQUEUE_PI, > but it's hitting the same 'too many parameters' limitation as well :/
We don't use val2 for FUTEX_WAIT_REQUEUE_PI, so we should be able to use that for setval.
-- Darren Hart IBM Linux Technology Center Real-Time Linux Team
| |