Question about semaphores and threads

[Alexander Boettcher]

Hi Adam & all,

here the calling graph, which seems to cause the issue:

lib/src/exit.c: __do_exit () the state is set to TCB_SHUTDOWN

Afterwards the thread in shutdown progress calls __do_cleanup_and_block() ->
l4th_stack_free ->
l4th_pages_free ->
l4rm_detach () ->
l4rm_lock_region_list() ->
l4lock_lock () ->
IPC to semaphore lib if locked
[! we have contention, threads in creation or in shutdown progress, 
otherwise no call to the semaphore lib is required] ->
get_prio () ->
sanity check TCB_ACTIVE

Here the data structure [l4th_tcb_t] is still valid and associated to 
the thread. This data structure is removed after l4th_stack_free() 
invocation by l4th_tcb_deallocate(tcb).

So it seems to be no problem in general, because the data structure is 
still valid and associated to the thread in shutdown progress. However a 
solution could be to extend the sanity check from tcb_active also to 
allow tcb_shutdown [bad/good don't know] or to move around the 
tcb_shutdown state [possibly bad idea] or to introduce another state and 
extend sanity check.

Best,

Alex B.

Marc CHALAND wrote:
> 2008/1/24, Adam Lackorzynski <adam at os.inf.tu-dresden.de>:
> 
>> No, the thread is still alive, the '(deleted)' just means that it has
>> already been unregistered at the name service.
> 
> Name service data is stored into fiasco data to be shown into jdb ?
> 
>> Could you verify the theory that the threadlib has some strange state at
>> that time? So basically that l4thread_get_prio is returning -L4_EINVAL
> 
> Yes, return value is -L4_EINVAL.
> 
>> and then what the value of l4th_tcbs[thread].state in l4th_tcb_get is
>> (include/__tcb.h).
> 
> state of thread is 4 : TCB_SHUTDOWN.
> Hope this helps ?
> 
> Regards
> Marc
> 
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers