[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 #1 from Joel Sherrill <joel.sherrill at oarcorp.com> 2011-10-28 09:19:49 CDT ---
I think this is the first patch to knock out.  So let's focus on this one
first.

I can see needing this for conceptual reasons. But I have a few concerns:

+ Simple: Fix the spacing in the i386 cpu file.  There are some extraneous 
  blank lines.

+ The CPU ports are not allowed to redefine score types.  They can define
  base types and helper methods.  The bitfield implementation is probably
  the simplest to see this in action on.  But it just redefines the 
  CPU helper methods and types for the most part.  We probably need to
  be more flexible about which classes of operations a CPU supports.  See 
  below.

+ Redefining the entire SMP_lock_spinlock_nested_Control seems heavy handed
  and breaks the bookkeeping.  If this is just about compare and swap, then 
  it seems that a single CPU dependent lock field is all we are talking 
  about.  That is the SMP_lock_spinlock_nested_Control type.

typedef struct {
  SMP_lock_spinlock_simple_Control lock;
  uint32_t  count;
  int       cpu_id;
} SMP_lock_spinlock_nested_Control;

The count and and cpu_id of the holding CPU should still be valid independent
of the locking method.  Right now, that is a uint32_t.  

typedef uint32_t SMP_lock_spinlock_simple_Control;

So it should be simple to have that be based upon a CPU type and 
then the CPU may or may not define helpers that implement the middle 
of the _SMP_lock_spinlock_simple_XXX methods.  

I think generic option A is "CPU has cmp/swap".  Your CPU must have
option B.  There is not an infinite set of types of instructions to 
implement for this type of atomic operation.  Can we generalize your
option B to have a name so another CPU with that operation just
defines the low level instructions.  The score/src/smplock.c simple
lock code then just has CPU has option A, option B, etc.

Since we don't know what type of instruction you have, we may be
proposing the wrong solution.  So you need to tell us what type of
instruction we are working with. 

Generally speaking, RTEMS porting is very fine-grained.  So reimplementing
an entire score method or structure that has generic information has to
be justified.





Two things documentation wise.

+ There is a CPU architecture porting guide.  These new options need to be
discussed there.  When porting to an architecture or adding SMP to an existing
architecture, you would need the rationale and helpful hints added here.

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