[Bug 1946] Asymmetric SMP mega-patch

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1946

Gedare <giddyup44 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giddyup44 at yahoo.com
         Depends on|                            |1455, 1809, 1910

--- Comment #6 from Gedare <giddyup44 at yahoo.com> 2011-10-27 19:08:28 CDT ---
(In reply to comment #5)
> >   prepend _Unlock_Critical_Secition to _ISR_Enable
> >   while there is a small number of which don't.
> 
> Some are possibly missing it, but quite many fix a deadlock/lack of lock, in
> fact. There are several places in the code we had to change this way.
> 
> The lock issue is partially resolved by PR1910.
> 
> We do have the code merged with newer version of RTEMS mainline, but it is not
> yet fully usable. We plan to make an updated code dump quite soon.

I think the lock issue should be spun off (pun not intended) and resolved
separately. In particular, if the current RTEMS spinlocks are
architecture-dependent then they need to be fixed to allow either an
independent implementation or an API that allows each CPU (or BSP if necessary)
to define their locking mechanism. Also I agree with Sebastian about needing to
fix current spinlocks (and atomic ops in general) to flash the ISRs.

Also, instead of using obscure Lock/Unlock_Critical_Section names, I think we
should be using the lock infrastructure with a global (big kernel lock)
namespace lock.  Later we can refactor obtaining the BKL to fine-grained locks.
 Grabbing the BKL then should either be done with or without interrupts
disabled dependent on the situation, and the disabling of interrupts should not
be made explicit or wrapped in the function that obtains a lock in general. It
is hard to evaluate the current implementation of Lock/Unlock_Critical_Section
until the implementation is included (right now it appears to be a
hardware-dependent callout to the __k1_recursive_lock). i see this is in
pr1809, marking it as blocking.

Basically I think that SMP locks need to be implemented better before we can
consider any of the code that relies on the bkl.

Probably all of the libcsupport patches can be separated and evaluated in
parallel to everything else. Thread management should be separated also,
although it relies on the bkl implementation so it should need to wait until
that is resolved. The new scheduler should also be submitted separately.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.