UNIX for Dummies Questions & Answers

I know its kinda silly but I've seen the texts consider one side - a thread executes and finishes its task but I was wondering what will happen if the process dies when the thread is still under execution... I somehow think that the thread will continue execution but am backing off from the fact that a thread shares the data and code of a process... If the process dies then there shouldn't be any data or code and so logically speaking (if there's logic that is ) there shouldn't be a thread... I seem to be going round in circles... What happens in reality?

And while reading further, I read about multithreading and that was just fine... But when it came to creating a distinction even between threads - user level threads and kernel level threads... I was somewhat not feeling comfortable... As a matter of analogy, if I think as a webbrowser having threads at the user level, it might be serving the user load a page at the same time loading an image in the background, then how can I think of kernel level threads as?

The POSIX model has threads executing within the context of a process. Then a process starts it automatically has one thread executing, the one that calls main. When exit is called the entire process and all threads contained evaporate.

A kernel thread means that the kernel has integral support for threads, some threading libraries implement threads entirely within user space of a process and can work on a non-threaded kernel.

There are pros and cons of each, but most UNIX operating systems now support threads at the kernel level to the kernel can manage the scheduling. With user-space threads, the process itself must manage the scheduling of threads.

Alright, that clears up some misconceptions that I had... So am I right in assuming that there can never be a situation where we might require the threads of a process after killing a process?

Threads aren't really visible outside of a process and are internal implementation details.

If you require a thread after the process containing it has died then you have a design problem.

Oh now I see... So the thread is something that pertains only to the process that it belongs to and no other process can inherit it...

As I keep reading I'm getting some real dumb doubts... I don't understand the difference between User Semaphores and Kernel Semaphores... Do they differ only based on where they are implemented...? In that case, I was wondering if two threads of the same process could be synchorinzed using a kernel semaphore if the threads themselves are implemented by a kernel.. I feel that kernel threads should never need semaphores while if they are being implemented at the user level, they can be synchronized using kernel semaphores...

I'm a little confused now so if there was any mistake, kindly correct me....

There are two type of threads.

1. Kernel threads, implemented by the kernel, synchronisation is performed by the kernel.

2. User threads, the kernel knows nothing about the threads hence no need for kernel semaphores, only user semaphores are needed.

As a programmer, if you use the an API such as pthreads you do not care whether the threads are implemented by the kernel or by a user library.

Ok understood... So to boil it down, when the process is in the user space, only we as the programmer can synchronize them using "semaphores that are implemented in the user space" And because the kernel has no idea about the threads that are going on in the user space, we cannot use kernel semaphores... On the other side, threads implemented at the kernel level can be synchronized using kernel semaphores... Am I right?

Yeah... Now my questions seem outdated I guess...