In many ways threads operate in the same way as that of processes. Some of the similarities and differences are:
Like processes threads share CPU and only one thread active (running) at a time.
Like processes, threads within a processes, threads within a processes execute sequentially.
Like processes, thread can create children.
And like process, if one thread is blocked, another thread can run.
Unlike processes, threads are not independent of one another.
Unlike processes, all threads can access every address in the task .
Unlike processes, thread are designed to assist one other. Note that processes might or might not assist one another because processes may originate from different users.
Following are some reasons why we use threads in designing operating systems.
A process with multiple threads make a great server for example printer server.
Because threads can share common data, they do not need to use interprocess communication.
Because of the very nature, threads can take advantage of multiprocessors.
Threads are cheap in the sense that
They only need a stack and storage for registers therefore, threads are cheap to create.
Threads use very little resources of an operating system in which they are working. That is, threads do not need new address space, global data, program code or operating system resources.
Context switching are fast when working with threads. The reason is that we only have to save and/or restore PC, SP and registers.
But this cheapness does not come free - the biggest drawback is that there is no protection between threads.
Blocking: The major disadvantage if that if the kernel is single threaded, a system call of one thread will block the whole process and CPU may be idle during the blocking period.
Security: Since there is, an extensive sharing among threads there is a potential problem of security. It is quite possible that one thread over writes the stack of another thread (or damaged shared data) although it is very unlikely since threads are meant to cooperate on a single task.