[Bug 1791] DispatchDisableLevel is not smp safe

[bugzilla-daemon at rtems.org]

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

--- Comment #2 from Joel Sherrill <joel.sherrill at oarcorp.com> 2011-05-11 16:32:19 CDT ---
I'll catch some of these and let jennifer catch the rest.

(In reply to comment #1)
> +   * The following declares the a smp spinlock to be used to control
> typo: s/the a/a
> 
> +  SCORE_EXTERN SMP_lock_spinlock_nested_Control
> _Thread_Dispatch_smp_spin_lock;
> I'm not sold on the name, unless this is the only lock that will be associated
> with any _Thread_Dispatch handler.  We should develop a consistent convention
> for lock names.

Agree on naming convention.  But for now, there are only two planned.  One for
dispatch disable critical sections and one for interrupt disable critical
sections.

I am implementing the latter now.  So suggestions appreciated.

> cpukit/score/inline/rtems/score/thread.inl:
> Function prototypes should be in .h files. Why aren't these functions inline in
> the SMP version?

Too complicated to inline.

> _Thread_Dispatch_set_disable_level(): This function confuses me. Why looping up
> and then down?

Since you lock/unlock as you go up and down, Jennifer thought this was the
safest level.  I don't know how many places it is actually used and would like
to analyse each one.  It is a replacement for direct assignments of a disable
level to the variable.  Makes one wonder if it could be enable/disable or
initialize in places.

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