Using pthread_yield to return control over the CPU back to Kernel

Question

Consider the following scenario: in a POSIX system, some thread from a user program is running and timer_interrupt has been disabled.

to my understanding, unless it terminates - the currently running thread won't willingly give away control over the CPU. My question is as follows: will calling pthread_yield() from within the thread give the kernel control over the CPU?

any kind of help with this question would be greatly appreciated.

Answer 1

Turning off the operating system's timer interrupt would change it into a cooperative multitasking system. This is how Windows 1,2,3 and Mac OS 9 worked. The running task only changed when the program made a system call.

Since pthread_yield results in a system call, yes, the kernel would get control back from the program.

If you are writing programs on a cooperative multitasking system, it is very important to not hog the CPU. If your program does hog the CPU the entire system comes to a halt.

This is why Windows MFC has the idle message in its message loop. Programs doing long term tasks would do it in that message handler by operating on one or two items and then returning to the operating system to check if the user had clicked on something.

Answer 2

It can easily relinquish control by issuing system calls that perform blocking inter-thread comms or requesting I/O. The timer interrupt is not absolutely required for a multithreaded OS, though it is very useful for providing timeouts for such system calls and helping out if the system is overloaded with ready threads.