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