[PATCH 9/9] score: Add and use _Objects_Release()

[Sebastian Huber]

On 06/06/2013 03:35 PM, Gedare Bloom wrote:
> On Thu, Jun 6, 2013 at 6:53 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>> On 06/05/2013 05:22 PM, Sebastian Huber wrote:
>>>
>>> Add and use _Objects_Release_without_thread_dispatch().  These two
>>> functions pair with the _Objects_Get() function.  This helps to
>>> introduce object specific SMP locks to avoid lock contention.
>>
>>
>> Maybe it is better to name it _Objects_Put().  So we have
>>
>> obj = _Objects_Get()
>> do_something_with_it(obj)
>> _Objects_Put(obj)
>>
> Yes I think "Put" is a better inverse operation to "Get". Though given
> the following discussion, might it be better to say "Acquire/Release"?
> Objects_Get already does a dispatch disable crit section, so the
> semantic meaning probably makes sense.

Maybe we have both in the future Get/Put and Acquire/Release.

>
>> For SMP it is desirable to gradually introduce more fine grained locking.
>> So we may add a SMP lock to Objects_Control and use new functions
>> _Objects_Acquire() and _Objects_Release() to protect the object state.  For
>> example a mutex obtain may use only the object specific lock if it is free
>> and use additional locks if it has to perform a blocking operation which
>> requires intervention of the scheduler.
>>
> Will there need to be new functions, or can "Get/Put" determine
> whether the object needs to be locked/unlocked?

I am not sure how this will be done in the future.  In order to introduce more 
fine grained locking you have to review each object implementation on its own. 
  It would be a huge effort to do this for all objects at once.  I am in favor 
of a step by step conversion and start with the most important objects, e.g. 
events and semaphores.

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