Re: [PATCH 5/6] futex: handle timeout inside adaptive lock spin

From: Darren Hart
Date: Wed Apr 07 2010 - 13:31:52 EST


Thomas Gleixner wrote:
On Mon, 5 Apr 2010, Darren Hart wrote:

Signed-off-by: Darren Hart <dvhltc@xxxxxxxxxx>
---
kernel/futex.c | 24 +++++++++++++++++++++---
1 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index c33ac2a..af61dcd 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2385,6 +2385,7 @@ out:
/**
* trylock_futex_adaptive() - Try to acquire the futex lock in a busy loop
* @uaddr: the futex user address
+ * @timeout: absolute timeout or NULL if none
*
* Try to acquire a futex lock in a loop until the owner changes or the owner
* is descheduled. To lock the futex, set the value to the current TID.
@@ -2394,10 +2395,11 @@ out:
* 1 - Futex lock acquired
* <0 - On error
*/
-static int trylock_futex_adaptive(u32 __user *uaddr)
+static int trylock_futex_adaptive(u32 __user *uaddr, ktime_t *timeout)
{
int ret = 0;
u32 curval;
+ ktime_t now;
for (;;) {
struct thread_info *owner;
@@ -2433,6 +2435,22 @@ static int trylock_futex_adaptive(u32 __user *uaddr)
if (need_resched())
break;
+ if (timeout) {
+ now = ktime_get();

Hmm. Calling that in every iteration might hurt especially on non
TSC systems, but well...

I haven't come across a better alternative since arming the timer before setting TASK_INTERRUPTIBLE isn't appropriate.


+/* FIXME: consider creating ktime_less_than(lhs, rhs) */

No need. The .tv64 comparison works in both cases. :)

Ah, for some reason I was thinking that was only the case if CONFIG_KTIME_SCALAR was set. Very nice, thanks.

--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/