[Bug 1813] SMP code: shared variable access

[bugzilla-daemon at rtems.org]

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

--- Comment #5 from Marta Rybczynska <marta.rybczynska at kalray.eu> 2011-06-13 10:22:27 CDT ---
(In reply to comment #3)
> (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.
> 

Also _Thread_Executing and _Thread_heir ? Those do not generally create
problems, but are accesses to _Per_CPU_Information.

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

This looks like a good summary and an OK scheme to use.

> 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 do not really care as long as the accesses are well protected.

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