bug-hurd
[Top][All Lists]
Advanced

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

libpthread: caching of data structures and kernel resources


From: Thomas Schwinge
Subject: libpthread: caching of data structures and kernel resources
Date: Fri, 10 Aug 2012 01:17:30 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.3.1 (i486-pc-linux-gnu)

Hi!

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.  This also applies to
kernel resources (cf. have_kernel_resources), that may also be re-used.
That is, on Mach, instead of thread_terminate, destroy wakeup port, and
later thread_create, create wakeup port, thread_set_state, thread_resume,
we can then just do thread_suspend, and later thread_abort,
thread_set_state, thread_resume as well as re-use the existing wakeup
port.

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?

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)?

sysdeps/viengoos/pt-thread-halt.c:

    void
    __pthread_thread_halt (struct __pthread *thread)
    { 
      /* We need to be careful.  This function is called in three
         situations: by the thread itself when it is about to exit, by a
         thread joining it, and when reusing an existing thread.  Hence,
         it must be kosher to interrupt this functions execution at any
         point: syncronization is difficult as in the first case, there is
         no way to indicate completion.  */
      if (thread->have_kernel_resources)
        { 
          if (thread == _pthread_self ())
            { 
              while (1)
                { 
                  vg_suspend ();
                  assert (! "Failed to suspend self.");
                }
            }
          else
            { 
              error_t err = vg_thread_stop (thread->object);
              if (err)
                panic ("Failed to halt " VG_ADDR_FMT ": %d",
                       VG_ADDR_PRINTF (thread->object), err);
            }
        }
    }

This has been introduced in
<http://git.savannah.gnu.org/cgit/hurd/viengoos.git/diff/libpthread/sysdeps/viengoos/pt-thread-halt.c?id=57487c9bf316f3ed262d17e4c10b284a263b8187>,
but that whole commit,
<http://git.savannah.gnu.org/cgit/hurd/viengoos.git/commit/?id=57487c9bf316f3ed262d17e4c10b284a263b8187>,
is too big for me to grasp.


Grüße,
 Thomas

Attachment: pgpXVdny6F2pT.pgp
Description: PGP signature


reply via email to

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