If I am correct, processes access devices by system calls to the kernel.

CPU and memory are also devices.

  1. when a process starts to run, does it get cpu and memory by system calls to the kernel?
  2. When a process runs concurrently with other processes, the kernel schedules their running in an interleaving way. Does the process also call system calls to the kernel, when it give up cpu and memory to a different process and when it regain them back?
  3. when a process finishes running, does it release cpu and memory also by system calls to the kernel?
  • Such questions are more suitable on Stackoverflow. – Hauke Laging Jan 11 '15 at 21:37

It doesn't as much "get" CPU, as it just runs on it. The kernel decides on which core and when and for how long the process runs. It schedules the tasks so that each process gets its time slices on the CPU: it runs for a while, then either after the time slice expires, or a system call occurs, the context is switched to another process. The state of the program is stored before the switch and restored when the kernel decides it deserve another slice of time, so that it doesn't even notice the time gap. The scheduling may vary - it may have a fixed timer (milliseconds usually), or it may be tickless... the kernel also manages the scheduling according to the priority of the process (nice). The process may be locked onto specific cores (taskset). For a multithreaded program, threads get their slices independently and may run concurrently. The kernel can suspend the program completely and resume it at a later time (triggered by SIGSTOP and SIGCONT).

The memory is virtualized. The pointers that you see in your programming languages are not physical blocks of memory, but virtual addresses remapped to the physical layer. The kernel serves RAM in pages (for instance, 4kB), and even shuffles them around a bit (a page may be swapped to the hard disk and only restored in RAM when you access it). mmap is one way to map a new page to some address (where the pages may refer to a file from the hard drive, mapped to the memory). However, when you dynamically allocate memory (malloc and other allocators), it is up to the allocator what to do. It usually calls sbrk syscall to request more space for its memory pool, or mmap for larger chunks - implementations may vary.

So, to sum up: the process priority and CPU affinities may be set, but the scheduler takes care of how and when the program runs, no need to interact with the kernel in any way. Memory is served in pages and requested through system calls. Once you allocated the memory, you access it without intervention of the kernel, simply through the virtual address space.



A process can lower its CPU priority (but not decrease it, man 2 setpriority). Furthermore it can put itself to sleep for a certain time. But it cannot decide how the CPU time it saves is given to other processes.

For the situation with threads see psusi's comment.

memory A new process gets an initial amount of RAM (I don't know, though, whether this is a kernel default value or given in the header data of the binary). If more RAM is needed then the process asks the kernel for more (see man 2 mmap).

Like with the CPU time a process cannot decide which process gets more memory if it releases some.

process exit

If a process exits (either by its own decision or by being killed) then the kernel frees its resources automatically. A process could release "all" of its RAM before exiting but there is no reason to do so. Instead is just calls _exit or exit_group.

  • 1
    The difference between a single threaded process and a multi-threaded one is only that all of the threads in a multi-threaded process share resources such as most of their ram and file handles. The scheduler doesn't differentiate between the two, so there are no special ways for threads within a multi-threaded process to choose how they are allocated cpu time beyond "normal" processes, which is to say, changing their priority and voluntarily sleeping. – psusi Jan 12 '15 at 0:20

Your Answer

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

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