Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update task notification scheduler suspension usage #982

Merged
merged 6 commits into from
Feb 7, 2024
Merged

Update task notification scheduler suspension usage #982

Changes from 4 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
8cd19b4
Update task notification scheduler suspension
Dazza0 Feb 5, 2024
661f141
Merge branch 'main' into change/ulTaskGenericNotifyTake_scheduler_sus…
paulbartell Feb 5, 2024
845a048
tasks.c: Fix typo
paulbartell Feb 5, 2024
e5bdeff
Merge branch 'main' into change/ulTaskGenericNotifyTake_scheduler_sus…
chinglee-iot Feb 6, 2024
07cb29d
Use a complete sentence in comment
chinglee-iot Feb 6, 2024
63c8d73
Check portGET_CRITICAL_NESTING_COUNT when scheduler is running
chinglee-iot Feb 7, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
210 changes: 86 additions & 124 deletions tasks.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3819,6 +3819,8 @@ void vTaskSuspendAll( void )

/* This must only be called from within a task. */
portASSERT_IF_IN_ISR();
/* This must never be called from inside a critical section */
chinglee-iot marked this conversation as resolved.
Show resolved Hide resolved
configASSERT( portGET_CRITICAL_NESTING_COUNT() == 0 );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aggarg @RichardBarry

Is this change alright? I know some ports such as the ARM_CRx_No_GIC push the critical nesting count as part of the task context:

    /* Push the critical nesting count. */
    LDR     R2, ulCriticalNestingConst
    LDR     R1, [R2]
    PUSH    {R1}

I'm worried that this change might be a breaking change for some ports/applications and was hoping for a deeper look into this PR from you two

Copy link
Member

@chinglee-iot chinglee-iot Feb 6, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using portGET_CRITICAL_NESTING_COUNT() here is okay to me. Sharing my observation here.
Critical nesting count should only be modified in critical section and context switch inside a critical section is not allowed in SMP. Use the following scenarios for discussion:

  1. portGET_CRITICAL_NESTING_COUNT() is greater than 1. This task is in a critical section and can read or update the critical nesting count without problem.
  2. portGET_CRITICAL_NESTING_COUNT() is 0. The task A may get preempted by task B while reading critical nesting count. Critical nesting count will be restore to 0 when the task B left critical section.


if( xSchedulerRunning != pdFALSE )
{
Expand All @@ -3840,14 +3842,7 @@ void vTaskSuspendAll( void )
* it. */
if( uxSchedulerSuspended == 0U )
{
if( portGET_CRITICAL_NESTING_COUNT() == 0U )
{
prvCheckForRunStateChange();
}
else
{
mtCOVERAGE_TEST_MARKER();
}
prvCheckForRunStateChange();
}
else
{
Expand Down Expand Up @@ -7676,83 +7671,67 @@ TickType_t uxTaskResetEventItemValue( void )
TickType_t xTicksToWait )
{
uint32_t ulReturn;
BaseType_t xAlreadyYielded;
BaseType_t xAlreadyYielded, xShouldBlock = pdFALSE;

traceENTER_ulTaskGenericNotifyTake( uxIndexToWaitOn, xClearCountOnExit, xTicksToWait );

configASSERT( uxIndexToWaitOn < configTASK_NOTIFICATION_ARRAY_ENTRIES );

taskENTER_CRITICAL();

/* Only block if the notification count is not already non-zero. */
if( pxCurrentTCB->ulNotifiedValue[ uxIndexToWaitOn ] == 0UL )
/* We suspend the scheduler here as prvAddCurrentTaskToDelayedList is a
* non-deterministic operation. */
vTaskSuspendAll();
{
/* Mark this task as waiting for a notification. */
pxCurrentTCB->ucNotifyState[ uxIndexToWaitOn ] = taskWAITING_NOTIFICATION;

if( xTicksToWait > ( TickType_t ) 0 )
/* We MUST enter a critical section to atomically check if a notification
* has occurred and set the flag to indicate that we are waiting for
* a notification. If we do not do so, a notification sent from an ISR
* will get lost. */
taskENTER_CRITICAL();
{
traceTASK_NOTIFY_TAKE_BLOCK( uxIndexToWaitOn );

/* We MUST suspend the scheduler before exiting the critical
* section (i.e. before enabling interrupts).
*
* If we do not do so, a notification sent from an ISR, which
* happens after exiting the critical section and before
* suspending the scheduler, will get lost. The sequence of
* events will be:
* 1. Exit critical section.
* 2. Interrupt - ISR calls xTaskNotifyFromISR which adds the
* task to the Ready list.
* 3. Suspend scheduler.
* 4. prvAddCurrentTaskToDelayedList moves the task to the
* delayed or suspended list.
* 5. Resume scheduler does not touch the task (because it is
* not on the pendingReady list), effectively losing the
* notification from the ISR.
*
* The same does not happen when we suspend the scheduler before
* exiting the critical section. The sequence of events in this
* case will be:
* 1. Suspend scheduler.
* 2. Exit critical section.
* 3. Interrupt - ISR calls xTaskNotifyFromISR which adds the
* task to the pendingReady list as the scheduler is
* suspended.
* 4. prvAddCurrentTaskToDelayedList adds the task to delayed or
* suspended list. Note that this operation does not nullify
* the add to pendingReady list done in the above step because
* a different list item, namely xEventListItem, is used for
* adding the task to the pendingReady list. In other words,
* the task still remains on the pendingReady list.
* 5. Resume scheduler moves the task from pendingReady list to
* the Ready list.
*/
vTaskSuspendAll();
/* Only block if the notification count is not already non-zero. */
if( pxCurrentTCB->ulNotifiedValue[ uxIndexToWaitOn ] == 0UL )
{
taskEXIT_CRITICAL();

prvAddCurrentTaskToDelayedList( xTicksToWait, pdTRUE );
}
xAlreadyYielded = xTaskResumeAll();
/* Mark this task as waiting for a notification. */
pxCurrentTCB->ucNotifyState[ uxIndexToWaitOn ] = taskWAITING_NOTIFICATION;

if( xAlreadyYielded == pdFALSE )
{
taskYIELD_WITHIN_API();
if( xTicksToWait > ( TickType_t ) 0 )
{
xShouldBlock = pdTRUE;
}
else
{
mtCOVERAGE_TEST_MARKER();
}
}
else
{
mtCOVERAGE_TEST_MARKER();
}
}
taskEXIT_CRITICAL();

/* We are now out of the critical section but the scheduler is still
* suspended, so we are safe to do non-deterministic operations such
* as prvAddCurrentTaskToDelayedList. */
if( xShouldBlock == pdTRUE )
{
traceTASK_NOTIFY_TAKE_BLOCK( uxIndexToWaitOn );
prvAddCurrentTaskToDelayedList( xTicksToWait, pdTRUE );
}
else
{
taskEXIT_CRITICAL();
mtCOVERAGE_TEST_MARKER();
}
}
xAlreadyYielded = xTaskResumeAll();

/* Force a reschedule if xTaskResumeAll has not already done so */
chinglee-iot marked this conversation as resolved.
Show resolved Hide resolved
if( ( xShouldBlock == pdTRUE ) && ( xAlreadyYielded == pdFALSE ) )
{
taskYIELD_WITHIN_API();
}
else
{
taskEXIT_CRITICAL();
mtCOVERAGE_TEST_MARKER();
}

taskENTER_CRITICAL();
Expand Down Expand Up @@ -7796,88 +7775,71 @@ TickType_t uxTaskResetEventItemValue( void )
uint32_t * pulNotificationValue,
TickType_t xTicksToWait )
{
BaseType_t xReturn, xAlreadyYielded;
BaseType_t xReturn, xAlreadyYielded, xShouldBlock = pdFALSE;

traceENTER_xTaskGenericNotifyWait( uxIndexToWaitOn, ulBitsToClearOnEntry, ulBitsToClearOnExit, pulNotificationValue, xTicksToWait );

configASSERT( uxIndexToWaitOn < configTASK_NOTIFICATION_ARRAY_ENTRIES );

taskENTER_CRITICAL();

/* Only block if a notification is not already pending. */
if( pxCurrentTCB->ucNotifyState[ uxIndexToWaitOn ] != taskNOTIFICATION_RECEIVED )
/* We suspend the scheduler here as prvAddCurrentTaskToDelayedList is a
* non-deterministic operation. */
vTaskSuspendAll();
{
/* Clear bits in the task's notification value as bits may get
* set by the notifying task or interrupt. This can be used to
* clear the value to zero. */
pxCurrentTCB->ulNotifiedValue[ uxIndexToWaitOn ] &= ~ulBitsToClearOnEntry;

/* Mark this task as waiting for a notification. */
pxCurrentTCB->ucNotifyState[ uxIndexToWaitOn ] = taskWAITING_NOTIFICATION;

if( xTicksToWait > ( TickType_t ) 0 )
/* We MUST enter a critical section to atomically check and update the
* task notification value. If we do not do so, a notification from
* an ISR will get lost. */
taskENTER_CRITICAL();
{
traceTASK_NOTIFY_WAIT_BLOCK( uxIndexToWaitOn );

/* We MUST suspend the scheduler before exiting the critical
* section (i.e. before enabling interrupts).
*
* If we do not do so, a notification sent from an ISR, which
* happens after exiting the critical section and before
* suspending the scheduler, will get lost. The sequence of
* events will be:
* 1. Exit critical section.
* 2. Interrupt - ISR calls xTaskNotifyFromISR which adds the
* task to the Ready list.
* 3. Suspend scheduler.
* 4. prvAddCurrentTaskToDelayedList moves the task to the
* delayed or suspended list.
* 5. Resume scheduler does not touch the task (because it is
* not on the pendingReady list), effectively losing the
* notification from the ISR.
*
* The same does not happen when we suspend the scheduler before
* exiting the critical section. The sequence of events in this
* case will be:
* 1. Suspend scheduler.
* 2. Exit critical section.
* 3. Interrupt - ISR calls xTaskNotifyFromISR which adds the
* task to the pendingReady list as the scheduler is
* suspended.
* 4. prvAddCurrentTaskToDelayedList adds the task to delayed or
* suspended list. Note that this operation does not nullify
* the add to pendingReady list done in the above step because
* a different list item, namely xEventListItem, is used for
* adding the task to the pendingReady list. In other words,
* the task still remains on the pendingReady list.
* 5. Resume scheduler moves the task from pendingReady list to
* the Ready list.
*/
vTaskSuspendAll();
/* Only block if a notification is not already pending. */
if( pxCurrentTCB->ucNotifyState[ uxIndexToWaitOn ] != taskNOTIFICATION_RECEIVED )
{
taskEXIT_CRITICAL();
/* Clear bits in the task's notification value as bits may get
* set by the notifying task or interrupt. This can be used
* to clear the value to zero. */
pxCurrentTCB->ulNotifiedValue[ uxIndexToWaitOn ] &= ~ulBitsToClearOnEntry;

prvAddCurrentTaskToDelayedList( xTicksToWait, pdTRUE );
}
xAlreadyYielded = xTaskResumeAll();
/* Mark this task as waiting for a notification. */
pxCurrentTCB->ucNotifyState[ uxIndexToWaitOn ] = taskWAITING_NOTIFICATION;

if( xAlreadyYielded == pdFALSE )
{
taskYIELD_WITHIN_API();
if( xTicksToWait > ( TickType_t ) 0 )
{
xShouldBlock = pdTRUE;
}
else
{
mtCOVERAGE_TEST_MARKER();
}
}
else
{
mtCOVERAGE_TEST_MARKER();
}
}
taskEXIT_CRITICAL();

/* We are now out of the critical section but the scheduler is still
* suspended, so we are safe to do non-deterministic operations such
* as prvAddCurrentTaskToDelayedList. */
if( xShouldBlock == pdTRUE )
{
traceTASK_NOTIFY_WAIT_BLOCK( uxIndexToWaitOn );
prvAddCurrentTaskToDelayedList( xTicksToWait, pdTRUE );
}
else
{
taskEXIT_CRITICAL();
mtCOVERAGE_TEST_MARKER();
}
}
xAlreadyYielded = xTaskResumeAll();

/* Force a reschedule if xTaskResumeAll has not already done so */
chinglee-iot marked this conversation as resolved.
Show resolved Hide resolved
if( ( xShouldBlock == pdTRUE ) && ( xAlreadyYielded == pdFALSE ) )
{
taskYIELD_WITHIN_API();
}
else
{
taskEXIT_CRITICAL();
mtCOVERAGE_TEST_MARKER();
}

taskENTER_CRITICAL();
Expand Down
Loading