Switching tasks suspends interrupts

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
mrjbom
Member
Member
Posts: 322
Joined: Sun Jul 21, 2019 7:34 am

Switching tasks suspends interrupts

Post by mrjbom »

Hi.
I have problems after my scheduler switches the task.
Using the task_switch(), the control is passed to the task01() function, the problem is that after the task01() ends, the control is not returned back(I expect the control to return to the pit_handler())
But this is not the main problem, the main oddity is that interrupts stop working when the task01() function is called, even though the interrupt flag is set. I have no guesses as to why task switching suspends interrupts.
What's going wrong?
Octocontrabass
Member
Member
Posts: 5885
Joined: Mon Mar 25, 2013 7:01 pm

Re: Switching tasks suspends interrupts

Post by Octocontrabass »

You switch tasks before sending the EOI, so the PIC thinks you're still handling IRQ0, and won't allow another IRQ0 or any lower-priority IRQs to occur.

Since IRQ0 is the highest priority, there are no other IRQs that can occur.
User avatar
bzt
Member
Member
Posts: 1584
Joined: Thu Oct 13, 2016 4:55 pm
Contact:

Re: Switching tasks suspends interrupts

Post by bzt »

Octocontrabass wrote:You switch tasks before sending the EOI, so the PIC thinks you're still handling IRQ0, and won't allow another IRQ0 or any lower-priority IRQs to occur.

Since IRQ0 is the highest priority, there are no other IRQs that can occur.
I agree. The OP is missing a proper EOI.

Cheers,
bzt
User avatar
mrjbom
Member
Member
Posts: 322
Joined: Sun Jul 21, 2019 7:34 am

Re: Switching tasks suspends interrupts

Post by mrjbom »

Exactly, you're right.

But, how can I get the return statement in task01() to return control back to pit_handler()?
Octocontrabass
Member
Member
Posts: 5885
Joined: Mon Mar 25, 2013 7:01 pm

Re: Switching tasks suspends interrupts

Post by Octocontrabass »

Set up the stack so the function will return to a function that performs the "end task" system call. The "end task" system call will remove the task from the queue, clean up (or enqueue deferred cleanup), and switch to another task in the queue.

One of the tasks in the queue is the one that switched tasks in the middle of pit_handler(). When you switch to that task, you'll return control to pit_handler().

You cannot return control to pit_handler() without another task switch.
User avatar
mrjbom
Member
Member
Posts: 322
Joined: Sun Jul 21, 2019 7:34 am

Re: Switching tasks suspends interrupts

Post by mrjbom »

Octocontrabass wrote:Set up the stack so the function will return to a function that performs the "end task" system call. The "end task" system call will remove the task from the queue, clean up (or enqueue deferred cleanup), and switch to another task in the queue.

One of the tasks in the queue is the one that switched tasks in the middle of pit_handler(). When you switch to that task, you'll return control to pit_handler().

You cannot return control to pit_handler() without another task switch.
I realized that I think using system calls will be even more convenient.

The main difficulty will be that OS will need to monitor the presence of the system call "end_task ()" instead of return () in user programs, because if it is not there, the program will hang in the queue.
User avatar
iansjack
Member
Member
Posts: 4834
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: Switching tasks suspends interrupts

Post by iansjack »

When you compile programs for your OS you should include startup code that calls "main()" and, on return calls your end_task() (more usually called _exit()) system call. It would be poor design to require the programmer to insert the system call at the end of every program. Always let the compiler do any standard work rather than relying on the programmer.
User avatar
mrjbom
Member
Member
Posts: 322
Joined: Sun Jul 21, 2019 7:34 am

Re: Switching tasks suspends interrupts

Post by mrjbom »

iansjack wrote:When you compile programs for your OS you should include startup code that calls "main()" and, on return calls your end_task() (more usually called _exit()) system call. It would be poor design to require the programmer to insert the system call at the end of every program. Always let the compiler do any standard work rather than relying on the programmer.
I think I can get the compiler to insert "_exit()" instead of "return" in the required places so that the program ends correctly.
Last edited by mrjbom on Fri Jul 10, 2020 7:12 am, edited 1 time in total.
nexos
Member
Member
Posts: 1081
Joined: Tue Feb 18, 2020 3:29 pm
Libera.chat IRC: nexos

Re: Switching tasks suspends interrupts

Post by nexos »

What happens is main() is called by the runtime. The runtime is the first code executed in an app, and it is a part libc. It calls global constructors, creates a heap, and calls main. main returns when execution is over and returns a value. It actually returns to the runtime. The runtime destroys its heap, calls global destructors, and lastly calls _exit() to exit the app/
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg
Post Reply