Mismatched _Thread_Enable_dispatch and _Thread_Disable_dispatch

Charles-Antoine Gauthier charles.gauthier at nrc.ca
Wed Jun 7 15:31:05 UTC 2000


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.

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!

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).

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.

P.S. What about CVS access to RTEMS?

-- 
Charles-Antoine Gauthier
Institute for Information Technology   Institut de technologie de
l'information
National Research Council of Canada    Conseil national de recherches du
Canada



More information about the users mailing list