Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
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
1  
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
1  
@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. –  Gilles Oct 4 '12 at 21:44

1 Answer 1

up vote 2 down vote accepted

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.

EDIT

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

share|improve this answer
    
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
    
Thanks for clarifying. :-) –  Arpith Oct 8 '12 at 10:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.