[Bug 1910] An option for architecture-specific SMP locks

[bugzilla-daemon at rtems.org]

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

--- Comment #18 from Marta Rybczynska <marta.rybczynska at kalray.eu> 2012-08-10 03:25:30 CDT ---
(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > This looks fine to me.
> > 
> > I am OK with this patch with two concerns:
> > 
> > + why unsigned int instead of the uint32_t? 
> >   I think you are staying close to "register" size types.
> > 
> Sebastian suggested using int. Yes the point is to stay closer to the natural
> word size.

This is not critical, but it is better to not be 32-bit only.

> 
> > + _CPU_cache_flush_1_data_line is a macro implemented in libcpu. It is not
> > available at the point in cpukit where smplock is compiled. It is also 
> > not defined for all architectures. 
> > 
> > This patch seems very simple if we can agree on what to do with
> > _CPU_cache_flush_1_data_line. Without knowing the CPU model, you can't reliably
> > depend on knowing how to do that.
> How about using rtems_cache_flush_multiple_data_lines(addr, num)? num=1 should
> result in flushing 1 line I would think. Of course this still requires that the
> architecture implement the function, but for those that do not it should just
> be an nop anyways.

The idea behind this is to have a macro/static inline that will introduce no
cost for architectures that do not need it. It is a kind of a memory barrier
that makes sure that the content of the lock has been written in such a way,
that atomic operation just after will see the new value.

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