1

Every instruction comes from main memory/RAM.

In a bootloader, at least on Intel and IBM PC firmware and designations, you have BIOS jump to a memory address to begin fetching instructions for whatever purpose, usually to load a kernel, when or where does the instance of a process begin?

The hardware stacks are limited, but does using them constitute for a process or thread?

My point simply is what makes something a "thread" or "process", as to opposed to just more bytes from memory? Where is the line drawn in this situation?

  • The distinction appears as soon as two or more contexts exist in the system, and the kernel provides a way to switch between the contexts. – rwong Mar 2 '13 at 18:48
  • Are you sure? I really don't think it works that simply. – user82988 Mar 2 '13 at 18:54
  • I also think context switching is more suited to multitasking kernels rather than just simply one process, multiple threads or not. That is why I am asking if something specific entails this. – user82988 Mar 2 '13 at 19:03
  • 3
    Thread/Process are OS concepts. But even then they are very generic terms. But "Processes" could be considered to be running programs that can be scheduled by the OS. A "Thread of execution" is (current register state/stack) also known as a context. A context is something that can be scheduled by the OS to run on a particular processes. A processes contains at least one thread. – Martin York Mar 2 '13 at 19:10
  • I knew all of that. That doesn't addres my question exactly though. – user82988 Mar 2 '13 at 19:33
3

The BIOS finds the kernel bootloader and jumps to that. The kernel loads process zero -- at this point the kernel has total control over the processor and RAM. When the kernel wants to start a new process, it saves the state of the current process, allocates space in memory for the new process, and loads the initial state of the new process. The stack is just some available space given to a process by the kernel. It works like the memory is allocated before the process starts and freed after the process ends. The stack is limited because for C it needs to be contiguous -- to extend the stack, the kernel has to use the MMU to map a space in memory. If you don't ask the kernel first, you go past the end of the stack into a region that the MMU marked as unreadable, causing an overflow.

There are a few ways to separate tasks.

Green threads are done by saving state and switching tasks without kernel support. The process would need to allocate new stack space or share stack space. Switching with green threads requires them to release control of the CPU and give it to another with a yield command or similar.

Kernel threads are given their own stack and task switching is done by the kernel's scheduler, and the kernel creates space for the thread's stack, but they belong to the same process so they can access the same memory.

Processes are segregated by the kernel, so they cannot access the memory of other processes under normal conditions. forking creates a new process with a copy (on write) of the memory used by the parent process.

I think these definitions are fairly typical, but a lot does depend on what the kernel and even language writers decided. For example, in Erlang, they use what I would refer to as "green threading" to create very light-weight threads, but describe these as "processes" (not unjustifiably, since they don't share memory).

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy