lkml.org 
[lkml]   [2002]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: CLONE_DETACHED and exit notification (was user-vm-unlock-2.5.31-A2)

On Fri, 16 Aug 2002, Jamie Lokier wrote:
>
> Quite. There is no lock; the the futex is used in its purest form, as
> a wait queue.
>
> TID = thread is alive
> zero = thread is gone

I don't disagree with using a futex, and the interface can be exactly the
same (ie "synchronize with thread exit" really becomes "futex wait for tid
address" as you point out). I think it's a wonderful interface, and for
people who don't use futexes, they'd never even _notice_ that they could
do so.

However, the thing that makes me slightly nervous is that it would make
the exit case a bit slower. Right now we just do a conditional write zero
to a virtual address (ie two instructions or so):

if (tsk->user_tid)
put_user(0UL, tsk->user_tid);

but if we were to use a futex, the code would need to be something
slightly more complex and slower (I'm adding the "only do this if
somebody else has the VM" test to avoid it for some cases):

if (tsk->user_tid && atomic_read(&tsk->mm->users) > 1) {
if (!put_user(0, tsk->user_tid))
sys_futex(FUTEX_WAKE, tsk->user_tid);
}

where that sys_futex will do a page table walk etc.

So yes, it's a lot more generic (and very pleasant to use when we want
to), but it does imply a fair amount of overhead.

So I'd like to know what the likelyhood of it being used as a futex is. If
90% of all users would like a futex, that's _wonderful_. No question that
we should do it. But if it's dynamically fairly rare to have this
"synchronize with thread exit", then we may be losing more than we win.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.092 / U:3.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site