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