[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libpthread: caching of data structures and kernel resources

From: Neal H. Walfield
Subject: Re: libpthread: caching of data structures and kernel resources
Date: Fri, 10 Aug 2012 09:15:01 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.8 Emacs/23.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

Hi, Thomas,

At Fri, 10 Aug 2012 01:17:30 +0200,
Thomas Schwinge wrote:
> libpthread applies some caching of data structures
> (cf. __pthread_free_threads; »state == PTHREAD_TERMINATED«) which after a
> thread has exited can be re-used for a new one.
> ...
> Is this an optimization, assuming the second sequence of operations is
> cheaper (is surely seems to be), as well as assuming that if a thread
> exits/is terminated, surely a new one is to be created soon after?  Is
> this *only* an optimization, or does the internal libpthread logic also
> require this for some other reasons?
> In pthread/pt-exit.c for »state == PTHREAD_JOINABLE«, the state is then
> set to PTHREAD_EXITED.  Then, in both pthread/pt-detach.c:pthread_detach
> and pthread/pt-join.c:pthread_join, in the PTHREAD_EXITED case, the
> kernel resources will explicitly be deallocated by calling
> __pthread_stack_dealloc and __pthread_thread_dealloc, but then the
> pthread structure kept for re-use by calling __pthread_dealloc.  Why are
> the kernel resources deallocated here, contrary to re-using them like in
> other cases?

This isn't an optimization.  This pattern is necessary to properly
manage the resources.  When a thread exists, it can't destroy all of
its own resources.  If a thread should clean up all its state, it
needs to free its stack and its kernel thread.  Once it frees one, it
is no longer able to free the other (it can no longer run).

> Why does Viengoos in
> sysdeps/viengoos/pt-thread-halt.c:__pthread_thread_halt have to do
> different things depending on whether »thread == _pthread_self« or not?
> I'm assuming that on Mach, we can just always do thread_suspend (and take
> care to do a thread_abort before re-using it)?

My recollection is that they are semantically equivalent in this case
(vg_suspend cause the calling thread to wait for a message;
vg_thread_stop marks the thread as not runnable), but vg_suspend is a
lot cheaper than vg_thread_stop.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]