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

[Ingo Molnar]

On Fri, 16 Aug 2002, Linus Torvalds wrote:

> 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.

having looked at threading libraries i can tell you that any library
writer who cares about performance would use a futex for exit
notification. We've got a performance test that compares
signal-notification and futex-notification:

  earth3:~/libc> ./p3 -s 100000 -t 1 -r 0 -T --sync-join
  Runtime: 1.208586749 seconds

  earth3:~/libc> ./p3 -s 100000 -t 1 -r 0 -T --sync-signal
  Runtime: 1.336826839 seconds

the sync-join variant uses a futex, the sync-signal variant uses a signal
to notify completion. Note that the test does not even use SIGCHLD because
that is slower, it uses SIGUSR1 [in the application code] and sigwait(),
to remove the signal handler overhead. The futex variant is still faster,
and with futexes being used for CLONE_CLEARTID it would be faster by about
~0.1 seconds.

(The kernel used is an uptodate 2.4-threading kernel with yesterday's APIs
backported, and glibc fitted to those new interfaces.)

sure, this solution is even less generic and thus a bit more dangerous of
being a libpthread-specific optimization [ ;) ], but i cannot think of any
more complex threading library - things like JVMs tend to have less
semantical needs.  And if someone wants signal-based notification then
it's still possible.

	Ingo