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