Re: CLONE_DETACHED and exit notification (was user-vm-unlock-2.5.31-A2)

From: Linus Torvalds (
Date: Fri Aug 16 2002 - 12:22:02 EST

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Fri Aug 23 2002 - 22:00:12 EST