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

[Gedare Bloom]

On Fri, Jun 7, 2013 at 12:26 PM, Joel Sherrill
<Joel.Sherrill at oarcorp.com> wrote:
> 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.
>
I think the per-object critical section is (should be) only a factor
for SMP. UP mode should continue to use the same kind of protection,
that is, dispatch disable, plus allocator or isr locks in some
situations. The way I see it from what Sebastian has said so far, we
will have something like,
Object_Get() // dispatch disable on local core / UP, optional isr disable.
Object_Acquire() // fine-grained lock on SMP, nop on UP
... do something
Object_Release() // fine-grained unlock on SMP, nop on UP
Object_Put() // unnest dispatch

But, we might be able to consider turning Object_Acquire/Release into
ISR_Disable/Enable on UP to replace Object_Get_isr_disable() in some
cases. That would have to be determined on a case-by-case basis
probably.

-Gedare

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