Gilles Chanteperdrix wrote:
> On Tue, May 13, 2008 at 10:26 AM, Jan Kiszka <[EMAIL PROTECTED]> wrote:
>>  @@ -1236,6 +1236,9 @@ void xnpod_delete_thread(xnthread_t *thr
>>                 xnthread_cleanup_tcb(thread);
>>                 xnarch_finalize_no_switch(xnthread_archtcb(thread));
>>  +
>>  +               if (xnthread_test_state(sched->runthread, XNROOT))
>>  +                       xnfreesync();
>>         }
> No, this does not look good. The point of deferring TCB freeing is
> that the TCB will be accessed shortly after it is freed.

By whom in this case? The thread was not active anymore. IIRC, the
use-after-release issue was related to self-deletions.

> IMHO, the right solution is to add a call to xnpod_schedule or even
> directly xnfreesyng in the right place (in skins code, after all
> threads have been freed)

Well, as I said, we should rather move all these syncs out of critical
sections. So better avoid xnpod_schedule.

I need to think about this a bit more, I'm afraid. It is safe to delete
the TCB once the terminating thread is scheduled away and its successor
of about to leave (or left) xnpod_schedule, right?


Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to