1
$\begingroup$

In general, my understanding is: the cpu is executing a process/thread until either it is interrupted, the scheduler kicks it out, or it's waiting for something else (I/O for example), when it's put in different queues (ready, waiting, etc). (Correct me if I'm wrong)

My question is, when one process is waiting information from another process (I guess, sleeping until a signal for it has been received). How does the cpu know how to wake that process? When it receives the signal will it be attempting to wake up all the processes with it? Is it marked somehow which processes are expecting which signals? What if the interrupt doesn't have this process id, but a general message to which the process is the only one waiting for it?

I've been trying to find a concrete response and read: https://learning.oreilly.com/library/view/operating-system-concepts/9781118063330/10_chapter03.html#chap3 https://medium.com/cracking-the-data-science-interview/how-operating-systems-work-10-concepts-you-should-know-as-a-developer-8d63bb38331f

Thanks in advance!

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ OS uses various data structures to find info, f.e. it can map message id to the id of process waiting this concrete msg $\endgroup$
    – Bulat
    Commented Apr 11, 2019 at 8:41
  • $\begingroup$ Please note that processes often have many threads, of which some may be running and some may be sleeping. Usually you don’t wake a process, but a thread within a process (and you may not even care which process the thread belongs to). $\endgroup$
    – gnasher729
    Commented Apr 15, 2019 at 6:31

1 Answer 1

Reset to default
2
$\begingroup$

TL;DR
The CPU doesn't know anything. The operating system (OS) knows it all.

The CPU is rather a stupid machine that activates one instruction at a time, without knowing what that instruction "means" nor to which program it "belongs". To the CPU eyes there is only a single program that runs (maybe, up to interrupts that "jump" to the interrupt service routine and then goes back to THE PROGRAM.

The program that does the magic and allows us running multiple programs "at the same time" over a single CPU is the OS. The OS keeps a list of processes that are ready to run, with all the information needed -- their priorities, their memory regions, the point in the code where they stopped, etc.

Every now and then a timer interrupt is received causing the scheduler (which is part of the OS) to run. The scheduler registers the process that was currently running as "stopped" and chooses one of the waiting processes, restoring its meta-date (stack, etc.), and jumps to the point where that process stopped last time.

This gives you the illusion of running multiple processes simultaneously. But at the bottom of it, there is only one program that runs -- the OS -- and it gives priority to (or, calls) user loaded programs.

Regarding your question about inra-process communication. Again, this is usually done via methods provided by the OS. When a process waits for a signal it calls an OS method that registers this process awaits a signal and blocks the processes, allowing other processes to run. When the other process needs to send data to the first processes it uses a OS method that records the data and its destination, and (eventually) awakes the destination process. From the point of view of the first process it got blocked on a OS function which returns only when new information arrives.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.