Thread (2 messages) 2 messages, 2 authors, 2015-07-18

Re: [RFC PATCH] getcpu_cache system call: caching current CPU number (x86)

From: Ondřej Bílka <hidden>
Date: 2015-07-17 22:43:53

On Fri, Jul 17, 2015 at 04:03:30PM +0000, Mathieu Desnoyers wrote:
----- On Jul 17, 2015, at 6:58 AM, Ondřej Bílka neleai@seznam.cz wrote:
[...]
quoted
quoted
If we invoke this per-thread registration directly in the glibc NPTL
implementation,
in start_thread, do you think it would fit your requirements ?
A generic solution would be adding eager initialization of thread_local
variables which would fix more performance problems.
Concretely, what code would be in charge of this initialization ?

What changes does "eager initialization" imply from the current
implementation ?
Now if you write

class foo{
public:
  foo(){
    printf("init\n");
  }
  foo(const foo &x){
    printf("init\n");
  }
  int bar()
  {
    return 32;
  }
};
thread_local class foo x;

Then constructor isn't called in all threads, only main as its lazily
initialized. You need to call x.bar() in each thread to cause
initialization.
quoted
Second would be write patch to libc adding function
pthread_create_add_hook_np to register function that would be ran after
each thread creation.
Do you suggest that this callback should be registered once per thread,
or somehow attached to pthread_attr_t ? As maintainer of lttng-ust,
where we need some control over our own threads, but where we want minimal
impact on the overall application, I would really prefer if we can attach
the callback to pthread_attr_t.
Could you elaborate. I was suggesting per-thread callback, what do you
want to do with pthread_attr_t?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help