[Bug 1813] SMP code: shared variable access

[bugzilla-daemon at rtems.org]

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

Gedare <giddyup44 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giddyup44 at yahoo.com

--- Comment #1 from Gedare <giddyup44 at yahoo.com> 2011-06-12 13:57:18 CDT ---
(In reply to comment #0)
> In the code submitted as PR 1796/cpukit, for instance in
> cpukit/score/src/smp.c:
> _SMP_Request_other_cores_to_perform_first_context_switch there are accesses to
> shared variables not protected by any locks. This will not work on an
> architecture without coherent caches. 
> 
> There are two possible options to resolve the problem:
> 1. All accesses to _Per_CPU_Information use the proper locks.
I agree that this should be done. FWIW I think "per cpu" variables in Linux are
considered private to a core, as opposed to being an array of state associated
with all cores.

> 2. Read accesses use a special BSP function like  bsp_smp_read_int() which
> provides the right access method. Additionally, all such accesses made to
> _Per_CPU_Information should cast _Per_CPU_Information to volatile. Forgotten
> volatile will easily lead to hard to debug bugs, so a separate function may be
> better also for this reason.
> 
This seems hard to scale and maintain, and is not as intuitive as using
lock-based approaches. However, if there is an advantage to this approach that
I don't see then it might be reasonable. I'm not sure why the variables would
need to be cast to volatile, since the access function should ensure
consistency with some memory barrier or coherency guarantees.

> I can provide a patch when the decision is made.

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