I was reading Linux Kernel Development by Robert Love, where I came across this

Linux takes an interesting approach to thread support: It does not differentiate between threads and normal processes.To the kernel, all processes are the same— some just happen to share resources.

I do not know much about OSs (aspire to know more) and kernels and hence the above quote raised a question about thread implementations in different OSs(at least the popular ones like Windows, Linux and Unix).

Can someone please explain the different techniques for providing thread-support in an OS? ( and optionally contrast them)

  • 1
    $\begingroup$ You may want to have a look at the answer to this question on stackoverflow. $\endgroup$
    – Pedro
    Jun 7 '12 at 9:19
  • $\begingroup$ This question seems to be about Linux specifically. As such, it is offtopic here and should be on Unix & Linux. If it is supposed to be a general OS question, please edit to clarify that. $\endgroup$
    – Raphael
    Jun 7 '12 at 12:06
  • $\begingroup$ @Pedro Thanks but it is not what I was confused about. That question (what I feel) is talks more about performance and locking issues and so on. I am interested in how are threads actually implemented and different possibilities $\endgroup$
    – Ankit
    Jun 7 '12 at 18:07
  • $\begingroup$ @Raphael Thanks. I would have put it in that place (only if I knew of that). So, my bad I did not search for Linux community on stackexchange. Can you please migrate it? $\endgroup$
    – Ankit
    Jun 7 '12 at 18:08
  • $\begingroup$ @Raphael, the question is about understanding the consequences of a various approaches to an operating systems question as I understand it. (btw, I don't think being linux specific makes a question off-topic here.) $\endgroup$
    – Kaveh
    Jun 7 '12 at 18:36

Threads and processes are execution contexts. They mostly differ only by the amount of shared state (memory, signal handlers, file descriptors,...) with the other execution contexts (processes share little with other processes; threads share a lot with the other threads in the same process).

Most OS keep the two things separated, and thus know about several kinds of execution context.

Linux kernel on the other hand has just one kind of execution context, which is able to share or not things with other. If you want a process, set it up so that it share little, it you want threads, set them up so that they share what they need. You can set things up so that they behave in a way unsuitable for the process/thread terminology.

The POSIX API commonly used when programming for Linux knows only about processes and threads and thus most programs don't really care about what is an implementation detail for them in the way responsibilities are divided between kernel and user space. Older implementations of threads leaked some the implementation details (ps showing threads, thread id and process id mixing up, ...) and didn't provide exact POSIX semantic in some cases (signal delivery was problematic IIRC).

  • 2
    $\begingroup$ I think you're missing some of the complexity of Linux's scheduler. It does know whether threads belong to the same process. There are userland threads, as well. Furthermore, this seems to be more of an SO answer, about the concrete implementation, than a CS answer, explaining the concepts. $\endgroup$ Jun 7 '12 at 22:21

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.