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.
Chris
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
