[PATCH 04/17] score: Add thread actions

[Gedare Bloom]

On Tue, Mar 25, 2014 at 11:36 AM, Gedare Bloom <gedare at rtems.org> wrote:
> On Tue, Mar 25, 2014 at 8:49 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>> Thread actions are the building block for efficient implementation of
>>   - Classic signals delivery,
>>   - POSIX signals delivery,
>>   - thread restart notification,
>>   - thread delete notification,
>>   - forced thread migration on SMP configurations, and
>>   - the Multiprocessor Resource Sharing Protocol (MrsP).
>> ---
>>  cpukit/score/include/rtems/score/thread.h     |   59 ++++++++++++++++++++++
>>  cpukit/score/include/rtems/score/threadimpl.h |   67 +++++++++++++++++++++++++
>>  cpukit/score/src/threaddispatch.c             |   33 ++++++++++++
>>  cpukit/score/src/threadinitialize.c           |    2 +
>>  4 files changed, 161 insertions(+), 0 deletions(-)
>>
>> diff --git a/cpukit/score/include/rtems/score/thread.h b/cpukit/score/include/rtems/score/thread.h
>> index 7147110..153537a 100644
>> --- a/cpukit/score/include/rtems/score/thread.h
>> +++ b/cpukit/score/include/rtems/score/thread.h
>> @@ -356,6 +356,62 @@ typedef enum {
>>  /** This macro defines the last API which has threads. */
>>  #define THREAD_API_LAST  THREAD_API_POSIX
>>
>> +typedef struct Thread_Action Thread_Action;
>> +
>> +/**
>> + * @brief Thread action handler.
>> + *
>> + * The thread action handler will be called with interrupts disabled and the
>> + * thread action lock acquired.  The handler must release the thread action
>> + * lock with _Thread_Action_release_and_ISR_enable().  So the thread action
>> + * lock can be used to protect private data fields of the particular action.
>> + *
> Why doesn't the caller of the handler release the lock and enable ISRs
> after the handler returns?
>
Nevermind, I see that the handler can release the lock and enable ISRs
sooner in case protection is not required.
-Gedare