What's the difference between Process Context and Process Control Block?

Question

I know that Process Context is something that is stored when a process is preempted, containing all the necessary info to restart the process at a later time.

I also know that the Process Control Block(PCB) contains all the necessary attributes of the process.

So, does that mean that the Process Context is a part of the PCB? Or is it the other way around? Or are these separate all together? Please help me understand where one ends and the other begins - as well as how they're used together.

What exactly is a process boundary?

Also, how is the PCB affected during a context switch (if at all)?

Answer 1

I think you are confusing the concepts of threads and processes.

Threads (aka tasks)
Processes do not get pre-empted, only threads get pre-empted.
A process can contain one or more threads which may run concurrently and/or time-sliced.
As long as there are current threads in the process (some or all of which made be paused) it is said to be running. When the last thread ends the process terminates. When a process is terminated forcibly by the operating system all its threads are terminated as well.

Process control block
The Process Control Block is the collection of information needed to define a process. In modern OS'es processes are (more or less) isolated and run in their own memory space.
The term process control block is not actually in use by any operating system and the various info needed to control a process is not actually stored in a single structure, as such the term is not all that helpful.

Threads are confined to a process
All threads inherit their properties from the process and have little room to alter these. It is the programmer's responsibility to make sure threads do not step on each others toes. Unlike processes there is no isolation between threads inside a process other than a dedicated stack and thread local storage.

Thread context
A thread context is not part of the PCB.
A thread context is simply a dumb of the current machine state (mostly CPU registers) before the thread was interrupted, in additon every thread gets its own dedicated stack and thread local storage.
The context a thread runs under can only be understood in terms of the process state (as defined in the PCB).
E.g. memory addresses inside process X do not make sense outside that process.

Process isolation
I've never heard of process boundary. I'm assuming you mean process isolation.
Every process runs in its own virtual address space and gets access to virtual resources (such as the screen) in such a way that one process cannot access the resources of another process.
In most operating systems this isolation is imperfect and resources in use by other applications can be easily accessed especially when processes have been started with equivalent attributes (e.g. same user id).

how is the PCB affected during a context switch (if at all)?

The PCB is not affected by a thread context switch.

Answer 2

As you described these are different things.

A Process Context is a run-time information of a particular process at any given time. It's all information needed for OS to restore a suspended process. It's basically CPU registers and process stack. But it's highly dependent on CPU architecture.

A Process Control Block is a group of information about a process for its life time. It includes but not limited to an ID, process relationship (children and parents), privileges, accounting, etc. These are more dependent to what OS provides than CPU architecture.

A process control block is a concept; meaning that you can implement however you want. It can certainly include a region for a process context.

However it's odd to say the other way around: "a process context includes a process control block". Because you don't need to save a process control block on every process switch.