UNIX Socket FAQ

A forum for questions and answers about network programming on Linux and all other Unix-like systems

You are not logged in.

#1 2008-07-12 07:26 PM

raedbenz
Member
Registered: 2008-07-11
Posts: 13

Re: process ,threads and system calls

Hi,
i am newbit to Linux. i have been reading many books and tutorials online about kernel and etc....
i feel like still i need a solid and simple example, that shows the difference among the three terms (process ,threads and system calls).
if we assume this "hello world" code:

#include <stdio.h>

int main(void)
{
	printf("Hello World");
	
	return 0;
}


In the above code which is the process? which is the thread and which the system call?
if u have a better example plz post it.
thanks

Offline

#2 2008-07-13 02:35 AM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: process ,threads and system calls

I don't know how much you know, so I'll keep it broad and simplistic.

Basically you need to know about how memory works, a bit about cpus and
the kernel.

Each program has its own memory address space, which is virtual meaning it
doesn't exist as such in hardware, but is a mapping to physical ram, nothing, or
something else. The important part is that different processes don't see each
others' memory space at all and can't access it. A process uses its memory to
store its state (global data, stack, heap) and to store the cpu instruction code
that's executed by the cpu for that process. So from a hardware point of view a
process is a stream of instructions that's sequently executed until it's interrupted
in some way (by doing a systemcall or by an interrupt), a memory mapping
(from virtual to real, and access bits: whether the memory is readable, writable,
executable), and a set of registers. The kernel also manages certain things per
process and makes processes much more tangible.

Threads are sort of processes that share certain state with each other, mainly
their memory address space. This means they can read and write the same
variables and execute the same code, and for all practical purposes run at the
same time, just like two processes do.

A systemcall is just a way of changing the cpu context from userspace to kernel
space and execute a specific kernel function. The kernel has more privileges than
normal code, mostly it has direct access to the rest of the hardware and can
modify the address space (change the mappings) of anyone, including itself.

So to take your example, all the code there will run within one process, in which
main() is called at more or less the start of the program execution, and the
process ends existing more or less after main() returns. It calls printf(3), and in
practise that means that most likely libc which implements printf(3) will call the
write(2) systemcall. To know if something is a systemcall it's useful to know that
all manpages of section 2 are in principle systemcalls and 3 are part of libc.
When you call e.g. write(2) you don't do a systemcall directly, but call a function
in libc which is named write() and which calls the real systemcall.

Offline

#3 2008-07-13 08:20 AM

raedbenz
Member
Registered: 2008-07-11
Posts: 13

Re: process ,threads and system calls

Offline

#4 2008-07-13 08:22 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: process ,threads and system calls

API is mostly unrelated, except that libc provides a standardized API to
applications, like the wrapper functions for systemcalls.

All programs are user space, you'll know when you really need to be working in
the kernel (when you can't do whatever you want to do in user space, which is
very rare).

There is no inherent benefit to using threads. It's one of many tools you can use
to design a program, and one design can be better than another. Threads provide
certain behaviour (basically multiple processes sharing the same address space),
and how you use that is up to you.

So compared to single threaded programs a multi-threaded one can have
multiple instruction streams having executed by the cpu. Basically this means
it's easier to do multiple things at the same time. But if done wrong the added
complexity of potential race conditions and deadlocks isn't worth it.

Compared to multiple processes multithreading can have a much lower overhead,
and be easier because all threads have the same memory view. Disadvantage is
that if one thread is buggy and scribbles the wrong memory all threads will go
down.

Offline

Board footer

Powered by FluxBB