Thread creation

[Norman Feske]

Hi Peter,

> So what i'm currently trying to do is that i'm trying to have a thread, whose
> purpose is to initialize some more genode threads as it results in the page
> faults for some reason. It seems that Genode doesn't like me creating and
> starting thread instances by another thread (ie. main creates thread1 -> thread1
> creates thread2), which I find weird if in actual fact that this actually is not
> meant to work. I created and started an instance of thread2 in the main function
> of my genode server, which resulted in that thread working, whereas creating and
> starting an instance of thread2 in thread1 does not seem to work. I have a
> question that may contribute to me coming up with a workaround to this problem.

creating threads from other threads should work as expected. Your
observation that thread creation from the main thread works but not
from any another thread suggests that your creator thread has a too
small stack. By default, the main thread has a pretty large stack (64K)
but for custom created threads, the typical stack size supplied as
template argument to the 'Thread' template is much smaller, in most
cases 4K or 8K. So could you try increasing the stack size to 64K
for your custom threads?

BTW, because this is a recurring problem, we currently investigate
changing the stack allocation such that stack overflows can be easily
detected and never corrupt data.

> Given that a thread may call a function that belongs to another class, is there
> any way for me to obtain the ID of the thread that is currently executing? In
> previous builds of OKL4, L4_Myself() could be used within a function which would
> return the ID of the thread that was executing when the given function executes.

In OKL4 2.1 there is no such system call. However, Genode provides a way
to do it anyway (using a special thread-bootstap protocol). By calling
the static member function 'Thread_base::myself()', the caller can
obtain its own 'Thread_base' object. This way, you can get the physical
thread ID using the 'tid()' accessor. Or even better, you can cast the
returned pointer to the specific thread class access the corresponding
context.

However, in general, I recommend not relying on this thread-local
storage (TLS) mechanism but rather pass the needed context as a pointer
to the code that needs to access it. According to our experience, TLS is
never needed when developing new code - you can always pass the context
to functions as argument. Our solely reason to introduce 'myself()'
was the need to reuse existing code (Linux driver, Qt), which already
relied on TLS. That said, I'd like to encourage you to look again at
your design to see if TLS is really a necessity. In my opinion, avoiding
the use of TLS yields to much better code.

Norman