Possible bug in _CORE_mutex_Seize()

[Joel Sherrill]

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?

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.



> -Phil
> 


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