[PATCH 8/9] score: Add _Objects_Release_for_get_isr_disable()

[Joel Sherrill]

I would like to make sure we are clear on what type of critical section this implies so we can adjust things in a smarter fashion.

Get now implies both no dispatching. There are also limited allocate/deallocate critical sections. And isr critical sections.

We are heading to per object critical sections which needs to be evaluated based on what the current uniprocessor locks provide. They may be conservative but the extra conservativeness may be needed in some cases.



Gedare Bloom <gedare at rtems.org> wrote:


On Fri, Jun 7, 2013 at 3:15 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 06/06/2013 05:42 PM, Gedare Bloom wrote:
>>
>> On Thu, Jun 6, 2013 at 9:54 AM, Sebastian Huber
>> <sebastian.huber at embedded-brains.de>  wrote:
>>>
>>> >On 06/06/2013 03:41 PM, Gedare Bloom wrote:
>>>>
>>>> >>
>>>> >>I don't understand the name of the function. What do you intend to say
>>>> >>with "Release_for_get_isr_disable"?
>>>
>>> >
>>> >
>>> >There are basically two functions to get an object by its identifier:
>>> >
>>> >_Objects_Get()
>>> >_Objects_Get_isr_disable()
>>> >
>>> >For _Objects_Get() we have _Objects_Release() (or _Objects_Put()) or
>>> >_Objects_Release_without_thread_dispatch().
>>> >
>>> >For _Objects_Get_isr_disable() I introduced
>>> >_Objects_Release_for_get_isr_disable() since these functions must be
>>> > used
>>> >pairwise.  This _Objects_Get_isr_disable() is an optimization for
>>> > semaphores
>>> >which doesn't work on SMP.
>>> >
>>
>> Would it be ok/better to call it _Objects_Release_isr_disable()?
>>
>
> I think this name suggests that we do a release and perform an
> ISR_Disable().
>
is it possible to use an argument to differentiate the two cases and
use the same function names (e,g, "_Obects_Get(get_isr_disable=true)
... _Objects_Release(get_isr_was_disabled=true)"?

I just think the name "_Objects_Release_for_get_isr_disable" is not
that good. But, I also don't have good suggestions for a different
name.


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

_______________________________________________
rtems-devel mailing list
rtems-devel at rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel