Threading Concept in Linux....?

The Linux kernel doesn't, everything in Linux is a process.

Yes

Processes in Linux can share certain resources with other processes. Libraries like pthread make use of this feature to bring threads to user-space. Threads in Linux are processes that share their process address space with other processes.

For a mored detailed explication have a look at

Task: AFAIK there is no official definition, i'd say something like "unit of concurrency"

Process: Each process has it's own address space

Thread: A thread shares it's address space with other threads

regards

Matthias

On 28 May 2007 04:19:36 -0700 Murali wrote: | Hi all, | | 1) I have a small doubt in Linux Basics. | Wether the Linux having threading concept ? | I heard Linux treat everything as a process ? Is it true ? | If not how can i found that linux suppport threading concept ? | | | 2) I would like to know the difference between Process/Thread and | Task.

Not really a whole lot, although what is difference is certain things are shared that need to be shared for threads.

| Can any one clarify my doubt...it will be great helpfull for me. | Thanks in advance

Linux threads work just fine. See pthreads API.

Be sure you understand all the methods of programming in threads. It is not for beginners.

That depends on what you mean by a "thread". I suppose to most people the main difference between threads and processes are that threads share things like memory pages and file handles. In Linux processes _can_ share memory pages and file handles. _Posix_ threads share time slices, so that a multi-threaded process is not granted more CPU time than a non-threaded process

No. That was true for he Linux Kernel up to v 2.4. Threads were done as processes sharing resources. The (Posix) Library made them look similar to (Posix-) threads.

With v 2.6 we have "NPTL" ("Native Posix Thread Library"). Here a process can get multiple threads with support of the Kernel. The (Posix) Library makes them real (Posix-) threads.

"Posix thread library".

see above

-Michael

And yet it seems (at least to me) that beginners are all too often the ones that are hot for using threads.

One reason for this is that concepts like select or poll are hardly known.

For some reason, as far as concurrent IO is concerned people often think of threading as the only possible solution for this kind of problem.

The reason for this might be the dominance of some non Unixoid OS though ;)

Sven

Don't you think that waiting for an event in a thread is better than wasting CPU time by polling.

If the OS provides a select() API for the event in question, it might be possible to avoid threads, though, as here the kernel driver will do the un-blocking for us, moving some of the complexity into the driver. IMHO, not a good idea for homebrew driver implementation.

-Michael

Of course, despite the name the Unix System call poll does not do polling, instead it is usually interrupt driven. Shurely this will depend on the implementation of the poll method in the particular device driver and some badly designed hardware might require polling at the kernel level.

Implementation of a poll method in a device driver is usually just a few lines of code and will enable poll(2) and select(2) in userland.

Writing multithreaded or multi-process code is not an easy task, thus it should IMO be avoided in favour of select/poll wherever possible.

Sven

Just to muddy the waters, Solaris (yes, I know, it's NOT an embedded Linux) has process, lighteweight process, and threads

Back to the subject (gasp!), I've used both approaches for similar server applications. The older system maintained its own run queue of pending and partially-completed queries, the main loop driven by incoming data from several sources via a wait-for-input POLL/SELECT. The application was totally responsible for saving all required context per query, scheduling the queries, timeouts, etc.

Another system used a thread per active query, so the Operating System/runtime-environment performed all context switching and scheduling. Each thread could block on I/O as required for its singlular-minded purpose. It was a nightmare to debug since many debuggers are NOT thread aware. And worse was debugging data corruption when multiple threads co-mingle access and modification. I had to write classes for thread-safe list and array access with a mutex in each to provide fine grain locking for maximum parallelism. Deadlock occured when multiple classes required atomic updates since threads held mutex locks in conflicting orders. The solution was to assure that locks are ALWAYS acquired in a strict order, which is HARD to verify if they're acquired by different functions and the calling-caller map looks like the US interstate map.

Threads are a nice facility that reduces the overhead of a full "heavy" process, but they're very fragile.