[Bug 1787] Adding nesting support to smp spinlock

[bugzilla-daemon at rtems.org]

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

--- Comment #5 from Gedare <giddyup44 at yahoo.com> 2011-05-06 14:11:11 CDT ---
(In reply to comment #4)
> + Adding documentation
> 
> + I thought we had decided to leave it as volatile, but can't remember why. 
> I'm sorry to have to ask but do you have a link to where the conversation was
> held?
> 
I didn't find exact references to this volatile field, although we spoke in PR
1729 about volatile a little bit. Basically, if the SMP_lock_xxx_Control
variable is only accessed between memory barriers (in "safe" critical
sections), then it should not be volatile.  At the very least, I would prefer
to have the volatile removed from the typedef -- if it is necessary, it should
be part of the function prototype. My intuition is that volatile is unnecessary
for the Control variable.

> + id field can go away
> 
> + Actually I did not set the cpu_id back to 0 in the release function.  I
> thought it would be helpful during debug to be able to look at the lock and see
> which cpu had locked it last.  It is set to cpu 0 initially so that it always
> starts out the same way.
> 
OK.

> + Attempting to remove any changes that were warning changes and just commit
> them to the head of the tree.

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