[Bug 2143] New: SMP: Inconsistent RTEMS chains API

[bugzilla-daemon at rtems.org]

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

             Bug #: 2143
           Summary: SMP: Inconsistent RTEMS chains API
    Classification: Unclassified
           Product: RTEMS
           Version: HEAD
          Platform: All
        OS/Version: RTEMS
            Status: NEW
          Severity: normal
          Priority: P3
         Component: cpukit
        AssignedTo: joel.sherrill at oarcorp.com
        ReportedBy: sebastian.huber at embedded-brains.de


Sebastian Huber wrote:
> On 2013-08-27 01:26, Chris Johns wrote:
>> Sebastian Huber wrote:
>>> On 2013-08-24 04:10, Chris Johns wrote:
>>>>> Thus the normal extract operation is not available on SMP. An extract
>>>>> variant which needs also the chain control as a parameter must be
>>>>> used.
>>>>
>>>> I think a node may need a back pointer to the chain control that
>>>> contains a
>>>> lock. I suspect we cannot have a single score chain control structure
>>>> for both
>>>> protected and unprotected operations and support the current extract.
>>>> I have
>>>> not looked at all the uses of extract in the code so I do not know if
>>>> the chain
>>>> control is available and even it is I think the node should handle
>>>> this.
>>>
>>> In order to use the back pointer you have to lock the chain, so this
>>> cannot be used. You have to know on which chain the node is.
>>>
>>
>> Yes you are correct. Should the locking be something the user of the
>> chains
>> should manage ? The chains is starting to become more and more complex.
>
> On single processor configuration the locking is done by the chains (ISR
> disable/enable) so I think there is no way out.

The RTEMS chains has protected, unprotected and now explicit and I am starting
to wonder if the API has become too complicated for users with too many
choices. Some choices work with SMP other do not. We really should have one
version that works in all cases however this means breaking the existing API.
On the other hand anyone not using the explicit API will break when moving code
to an SMP target and only finds out once they move or try. They may have made
design choices without being aware of the differences and possible issues. The
one related to this change is the need to have the chain control available when
extracting a node. This is a big difference.

I understand the migration and the need not to break an API however I am asking
the question about the complexity of the API and if we should review what it is
doing. With this change where you need the control chain to extract the node
you have some data following the node and that could contain the lock and I
suspect in a number of cases will contain a lock. I also wonder if the user of
the chain can manage the locking better in some cases than letting the chain do
it. The locking was fast before and now it is not as fast changing the dynamic.

Extending the API makes sense now and from a kernel change point of view
however I am not convinced of the long term benefit when all the current rapid
change settles and is forgotten.

> Please have a look at the patch here:
>
> https://www.rtems.org/pipermail/rtems-devel/2013-August/004370.html
>
> I had to add rtems_chain_explicit_extract() and
> rtems_chain_explicit_insert() routines.
>

I understand the reason you have added the extra call. We either need to break
the existing API or extend the current one. Having two APIs is not helpful to
users and we need just one. If there is an agree path to one API I would be
happier. It could be a warning for non-SMP that the API will change.

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