I read somewhere that Linux threads are really implemented as processes in the kernel since with today's hardware and on the Linux platform, the thread model is inefficient compared to the process model. If this is the case then why do we still use pthreads programming in our projects (other than for backward compatibility)? Why is there so much hesitation in deprecating the pthreads model in Linux?

  • Are you asking why Threads are still in use? Or why Posix Threads are still in use?
    – Karlson
    Oct 4 '12 at 13:00
  • A bit of both I guess.
    – Arpith
    Oct 4 '12 at 13:03
  • 2
    I think you're not seeing pthreads correctly. pthreads is an API to allow programmers to write threaded code. The actual threads are normal Linux threads, which are indeed extremely close to ordinary processes on Linux. pthreads aren't "inferior" threads in any way.
    – Mat
    Oct 4 '12 at 15:17
  • So if the threads are implemented as processes (called tasks in Linux) then why do programmers still use the threaded approach since it is pretty obvious that their code eventually will translate to a task and not a thread as they planned?
    – Arpith
    Oct 4 '12 at 19:01
  • 2
    @Arpith For most uses, whether a thread is a separate task in the kernel is an irrelevant implementation detail. The programmer wants a thread and gets a thread. Oct 4 '12 at 21:44

Judging by the question you pose you probably haven't seen problems where Threads provide an advantage over the standard processes.

There are problems like High-Frequency Trading for example where system becomes sensitive to the number of context switches in the system as well as switching from user to kernel mode and back. In this case ability to work within a single memory space and have light context switches or no context switches at all give performance increases enough to worry about it. In addition if you have multiple processes handling stream of data coming in you don't want to implement a dispatcher copying data to an available process since you will have to create queues in shared memory or use network based IPC to copy data from and to the various processes memory spaces whereas with threads you read and parse the data once and keep it internally where any thread can access that particular event as needed making execution that much faster.

In addition there are tasks that can manipulate same data at different times or the same time, in which case it becomes much easier to make sure that you are not trampling over the updates from a different update process(thread).

Given these and many more problems where a single process space become advantageous you can see the necessity of threads. Now as far as Pthreads are concerned. You don't have to use them but they provide standardization and hence portability of source code across platforms.


The original question appears to mention the LinuxThreads which was implementing Threads entirely in User Level and at the Kernel level had to be handled as processes because those were the only kernel schedulable entities available. As of 2.6 kernel this is no longer the case. NPTL implements threads at the kernel level as schedulable entities.

You can also look at the similar question on StackOverflow

  • I'm sorry but you have missed my point completely. You are talking about generic threads and the normal stuff about how context switch are expensive to the kernel between processes compared to threads, which any decent operating systems text will talk at length about. My question is whether IN LINUX threads (which are implemented as processes in the kernel space, I believe) provide any advantage over being used as independent processes in user space.
    – Arpith
    Oct 4 '12 at 18:59
  • @Arpith Answer amended.
    – Karlson
    Oct 4 '12 at 20:17

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.