Possible bug in _CORE_mutex_Seize()

[Till Straumann]

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.

Note that I had added the paranoia check outside of the 'trylock'
call so we catch those kinds of errors ASAP and not only in the
unlikely/rare case where 'trylock' fails.
However, this requires checking for the system state - until multitasking
is up, 'trylock' never fails and it is hence safe to acquire the
lock during thread-dispatch disabled sections (happens e.g. during
RTEMS_Malloc_Initialize()).

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

Why not leave the original 'rtems_fatal_error_occurred()' in place
(never returns) ?

BTW: IMO the 'memset' is only necessary in the #else branch of #ifdef __GNUC__;
REENT_INIT_PTR() should take care of proper initialization (saving cycles).

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

T.

(my revised version attached)

> 
> -Phil
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: coremutex_seize_paranoia-1.diff
URL: <http://lists.rtems.org/pipermail/users/attachments/20030930/2d0cdcd7/attachment.ksh>