SMP: ISR disable/enable vs. mutual exclustion

Sebastian Huber sebastian.huber at embedded-brains.de
Tue Aug 27 08:31:50 UTC 2013


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

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the devel mailing list