capture engine thread safety
Till Straumann
strauman at slac.stanford.edu
Wed Feb 18 21:40:21 UTC 2009
Looking at the capture engine it seems
to me that regarding thread-safety
it is better than cpuuse and
rtems_iterate_over_all_threads().
However, unless I'm missing something, the
capture engine and it's API (some
inline functions there) still access
the TCB too carelessly:
Consider e.g., rtems_capture_task_state:
static inline States_Control
rtems_capture_task_state (rtems_capture_task_t* task)
{
if (rtems_capture_task_valid (task))
return task->tcb->current_state;
return 0;
}
Unless thread-dispatching is disabled
around this function the inspected task
could well be deleted between the
'valid' check and accessing task->tcb->current_state
(which would result in a NULL-ptr deref since
the 'task-deletion' hook sets task->tcb=0).
IMHO the aforementioned routine should rather be
static inline States_Control
rtems_capture_task_state(rtems_capture_task_t *task)
{
States_Control rval;
_Thread_Disable_dispatch();
rval = rtems_capture_task_valid(task) ? task->tcb->current_state : 0;
_Thread_Enable_dispatch();
return 0;
}
(for really fast operations like this one
disabling interrupts may be cheaper)
everything else should be modified accordingly.
Most notably: rtems_capture_task_stack_usage()
which then becomes a quite expensive operation in
terms of impact on latency but the algorithm could
be improved (e.g., by remembering the last 'dirty-top'
and scanning in 'chunks' where thread-dispatching is
disabled around a 'chunk_scan').
RFC
-- Till
More information about the users
mailing list