[Bug 1813] SMP code: shared variable access

[bugzilla-daemon at rtems.org]

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

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

There is nothing bad in it being a table, but the accesses must be done
in a well-defined way.

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

Myself I prefer a lock, but I've seen how the accesses had been done in PR
1796/cpukit and other places. It seems to me that Joel&Jennifer may prefer not
using locks. I launched the discussion to make sure :)

Probably it wasn't totally clear what I wrote about volatiles, but I meant that
just direct accesses require volatile in loops etc. This volatile can be easily
forgotten, so if it is needed, there may be a special function doing this.

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