Processes in Operating Systems.

Privileged processes:  Linux:root  Windows:Administrator, elevated  Mac:root,Administrator

What should privileged processes be allowed to do that other processes should not be allowed to do?

Root on Linux has complete access to all files no matter what the file privileges are.  (With potentially the exception of execute.  In certain case, even root can't execute a program without the execute bit.)

Root on Mac has complete access to ALMOST all files, but there some critical files that the only the OS can access.  (You can change this setting in a certain administrative menu.)

Windows administrator can access every file on the system.

Generally speaking, elevated processes can access, add, delete files even without any privileges at all.

Well, you don't want just anyone terminating existing processes.  In Linux, the termination command is kill.  On Linux, you can kill any process you own (with your userid).  But only root can kill anything it wants.

On Linux, only root can command autonomous robots to actually hunt down and shoot human beings.

On most systems, only an elevated process can change the system clock.

Certain peripheral settings, certain printer settings, you might not want the world to be able to do.

In ye olden days, when resources were more limited, you might not want regular processes to hog disk space or processor use or other stuff.

On most modern OS's you have two basic kinds of processes : administor (or root or elevated), everything else (normal).

Now older machines, even Windows 98, didn't use privileges at all.  And iOS, or Android, the privileged processes are are deeply held by the OS itself.

IPC:  Interprocess Communication.  How does one running process send a message to another running process?  Pipes on Linux.  Sockets (are mostly used to send information to another machine, but you are sending a message to another process or OS that is responsible for network communication).

On Linux, pipes are used between parent and child, but they're really not used between two unrelated processes; a more sophisticated system would be needed for this.  But there are hardware and software conventions to facilitate this should the need arise.

There are two major ways to accomplish IPC:

One is a message passing system (like pipes, but more general) where you send a sequence of bytes as a message and that message is received by another process.

I use MPI for this.  In ye olden days, I used MPL, which was similar.  Messages can be sent or received blocking or non-blocking.

Block send:  your program blocks after the message sent until the message is received by the other process.

Nonblock send:  Your program sends the message and then continues; it's stored in a buffer that may be eventually read by the recipient.

Block receive:  Your program blocks while waiting for a message and remains blocked until the message is received in its entirety.

Nonblock receive:  Your program initiates a receive, then goes on to do other stuff and checks back periodically to see if the message has been received yet.

The most common reason a receiver needs to block while receiving a message is that the sender hasn't sent it yet.

In 444, we tend to use nonblock send/block receive because that's the easiest to master for people who haven't done this sort of thing before.

block send/block receive makes better use of resources.  The OS doesn't hae to store the message in a temporary buffer while it waits to be received.

nonblock send/nonblock receive utilizes parallelism better as you can do other stuff while the message is being transmitted.