[Bug 1813] SMP code: shared variable access

[bugzilla-daemon at rtems.org]

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

--- Comment #3 from Joel Sherrill <joel.sherrill at oarcorp.com> 2011-06-13 09:39:54 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.

There is no reason to do this because AFAIK all OS proper accesses are within
thread dispatch disable sections.  This locks the structure.

When touching the message field, the lock in the per cpu is grabbed.

When calling _SMP_Request_other_cores_to_perform_first_context_switch(),
the secondary cores are in a known state and we can take advantage of it.

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

Gedare has been arguing against volatile for these fields.  I am ambivalent
because I am more worried about the impact of caching than volatile.  We are
pretty careful to use compiler memory barriers with the critical sections. That
is stronger than volatile because nothing else should change the value while it
is locked.

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