Mismatched _Thread_Enable_dispatch and _Thread_Disable_dispatch

[Joel Sherrill]

Charles-Antoine Gauthier wrote:
> 
> In
> 
> rtems/c/src/exec/score/src/objectget.c(_Objects_Get) and
> rtems/c/src/exec/score/src/objectgetbyindex.c(_Objects_Get_by_index),
> there is no matching _Thread_Enable_dispatch() to the
> _Thread_Disable_dispatch() when an object pointer is returned.
> 
> I am thinking that this might be a explicit design decision rather than
> an oversight and that you intended the caller to re-enable dispatching.
> In this way, the caller is guaranteed that the returned pointer points
> to an existing object until the caller re-enables dispatching (or
> deletes the object itself). Unfortunately, this is not documented.
> 
> Was that the intent or is this a bug? I wont "fix it" if the code is
> "correct", I will just add the _Thread_Enable_dispatch() in the right
> places.

It is a VERY deliberate design decision.  When _Objects_Get* returns
an object pointer, you are ensured that dispatching is disabled.
If you look at RTEMS services, you will generally see this pattern:

  error check parameters
  
  the_XXX = _XXX_Get( id, &location ); /* wrapper for _Objects_Get */
  switch ( location ) {

    case OBJECTS_REMOTE:
      make remote call

    case OBJECTS_ERROR:
      return invalid id error

    case OBJECTS_LOCAL:

      any error checks that require the_XXX object pointer to make

      do operation on the_XXX object.      

      _Thread_Enable_dispatch();
      return successful status
  }

> I found out about this issue the hard way. I attempted to use
> _Object_Get_by_index() to get the object id of ITRON tasks given only
> their index. I looked up three tasks and ended up in my main task with
> _Thread_Dispatch_disable_level set to 3!

:) And that totally hosed the system I am sure. :)

> I then looked for all threads (of all types) using _Object_Get_next().
> That got me into trouble also. (I will try using
> rtems_monitor_manager_next() directly rather than roll my own now that I
> found out that this function exists).

Good idea.  

> The point of the exercise is to push all thread stacks onto the marking
> stack of the Boehm Garbage Collector. To do this, we need to find all
> threads, and then find their stacks and stack pointers. As you can see,
> we are trying to get the last bit of the gcj/libgcj technology ported to
> RTEMS.

I think there is a loop in the monitor code to cycle over all tasks.
Definitely there is one in the usage report generator in the stack
checker.

What about a "create" user extension that marks the stack?  Don't you
need to mark new tasks as well?

> P.S. What about CVS access to RTEMS?

That one is for Mark to answer.  Ask mark.johannes at OARcorp.com. :)
 
> --
> Charles-Antoine Gauthier
> Institute for Information Technology   Institut de technologie de
> l'information
> National Research Council of Canada    Conseil national de recherches du
> Canada

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985