# Why we can't access ready list in ISR handler

**URL:** <https://forums.freertos.org/t/why-we-cant-access-ready-list-in-isr-handler/10554>\
**Category:** Kernel\
**Created:** [August 27, 2020, 8:33am UTC](https://forums.freertos.org/t/why-we-cant-access-ready-list-in-isr-handler/10554 "2020-08-27T08:33:36Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![maidoumaizo](https://avatars.discourse-cdn.com/v4/letter/m/ecd19e/32.png) [@maidoumaizo](https://forums.freertos.org/u/maidoumaizo)\
**Post date:** [August 27, 2020, 8:33am UTC](https://forums.freertos.org/t/why-we-cant-access-ready-list-in-isr-handler/10554/1 "2020-08-27T08:33:36Z")

</div>

In xTaskResumeFromISR function，we put resumed task in xPendingReadyList if schedule was suspended  
 ![image](https://d2v6vdsk2p900z.cloudfront.net/original/1X/9b4730249e13d6a3682c412f114a34518e335442.png)

but why we can’t access ready list in ISR handler, in xTaskResumeFromISR function, we also call portSET\_INTERRUPT\_MASK\_FROM\_ISR to mask interrupt

In xTaskResume function，we also access ready list after masking interrupt whether scheduler is suspended  
 ![image](https://d2v6vdsk2p900z.cloudfront.net/original/1X/1be88402265d682ffcc029779de83b251e4b66ab.png)

---

<div class="post-metadata">

**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\
**Post date:** [August 27, 2020, 12:18pm UTC](https://forums.freertos.org/t/why-we-cant-access-ready-list-in-isr-handler/10554/2 "2020-08-27T12:18:00Z")

</div>

One of the major reason to suspend the schedule is to do some operations on the ready list that might take some time, so we don’t want to disable interrupts. The non-ISR version can access it because it knows that if the scheduler was disabled WE DID IT, therefore it is allowed to access it.

---

<div class="post-metadata">

**Author:** ![maidoumaizo](https://avatars.discourse-cdn.com/v4/letter/m/ecd19e/32.png) [@maidoumaizo](https://forums.freertos.org/u/maidoumaizo)\
**Post date:** [August 28, 2020, 1:39am UTC](https://forums.freertos.org/t/why-we-cant-access-ready-list-in-isr-handler/10554/3 "2020-08-28T01:39:54Z")

</div>

Thanks for your help~  
So you mean sometimes we implement portSET\_INTERRUPT\_MASK\_FROM\_ISR as an empty macro, so we can not disable interrupts in ISR

---

<div class="post-metadata">

**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\
**Post date:** [August 28, 2020, 11:20am UTC](https://forums.freertos.org/t/why-we-cant-access-ready-list-in-isr-handler/10554/4 "2020-08-28T11:20:15Z")

</div>

No, but ports that don’t allow nested interrupt might do that as without nested interrupt you don’t need that operation.

The issue you referenced above is that sometimes a task will suspend the scheduler because it has to do a longer operation on the tasks lists will suspend the scheduler so nothing interferes with the operation. They don’t disable interrupts, as that could be too disruptive, but it does mean that an interrupt shouldn’t access or alter the task lists as they might be in the process of being changed. Thus, if the scheduler is suspended, task that would be moved to the ready list are instead added to a special list of tasks that will be checked when reenabling the scheduler.

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [August 28, 2020, 1:14pm UTC](https://forums.freertos.org/t/why-we-cant-access-ready-list-in-isr-handler/10554/5 "2020-08-28T13:14:45Z")

</div>

> [@richard-damon](#):
>
> The issue you referenced above is that sometimes a task will suspend the scheduler because it has to do a longer operation on the tasks lists will suspend the scheduler so nothing interferes with the operation. They don’t disable interrupts, as that could be too disruptive, but it does mean that an interrupt shouldn’t access or alter the task lists as they might be in the process of being changed. Thus, if the scheduler is suspended, task that would be moved to the ready list are instead added to a special list of tasks that will be checked when reenabling the scheduler.

That’s right. As per the book text, critical sections use interrupt mask and unmask to implement a critical section. That protections the critical section from both tasks and interrupts. It is efficient for very short sections of code but you don’t want to keep interrupts disabled for long sections of code. Scheduler suspending/resuming leaves interrupts enabled, so critical sections implemented with scheduler suspending and resuming only protections the critical section from other tasks, not form interrupts, and interrupts are restricted in what they can do so as not to break the critical sections. Ready lists are assumed to be protected when the scheduler is suspended so interrupts don’t touch them and instead use a pending ready list. When the scheduler is resumed any tasks in the pending ready lists are moved to their appropriate ready lists.
