Possible bug in _CORE_mutex_Seize()
joel.sherrill at OARcorp.com
Tue Sep 30 21:18:21 UTC 2003
Phil Torre wrote:
> I'm running now with some of the changes suggested by Till and Joel:
> 1. "Paranoia" added to _CORE_mutex_Seize() which checks
> _Thread_Dispatch_disable_level and throws an internal error if
> its nonzero when it shouldn't be.
Be careful with this one. I don't think this is the right place to
check it. You can attempt to obtain a mutex in an ISR and
_Thread_Dispatch_disable_level will definitely be non-zero. You
can't use the Allocator Mutex when _Thread_Dispatch_disable_level
is non-zero but it is conceivable that you could use another mutex.
I would take this out.
> 2. The reent struct is now allocated from the workspace using
> _Workspace_Allocate() from libc_create_hook rather than the start
> hook. If _Workspace_Allocate() returns NULL, the create hook
> returns false.
> This seems to be working (given several minutes of exhaustive testing),
> but I notice a few things: Since I'm now calling _Workspace_Allocate()
> directly, _RTEMS_Allocator_mutex is not being locked. That should be
> OK, because _Thread_Dispatch_disable_level is nonzero, correct?
It should be right because _Workspace_Allocate() is a normal part of
rtems_task_create(). The stack, FP context, and API extensions
are allocated from the Workspace as part of task creation.
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
More information about the users