UNIX Socket FAQ

A forum for questions and answers about network programming on Linux and all other Unix-like systems

You are not logged in.

#1 2007-07-10 11:59 AM

kumar_1122
Member
Registered: 2006-12-29
Posts: 14

Re: understanding threads

HI,

I have few doubts in understanding thread concepts..
Please help me in correcting my basics

1. What is scheduler activations ?

2. What is process run time system ?

3. How to design variables global to thread and not to entire program..

4. How to turn single thread into multiple threaded program.

5. What are the factors that decide the speed of the thread ?

6. How do we call functions ion other threads ?

7. what is Disjoint address space?

8.  Are p-threads user threads or kernel threads ? How can we differentiate between them ...How to program kernrl threads...

9. How two processes can share some address space ?

Offline

#2 2007-07-10 06:32 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: understanding threads

Offline

#3 2007-07-12 07:37 AM

kumar_1122
Member
Registered: 2006-12-29
Posts: 14

Re: understanding threads

HI,

Thanks a lot for the clarifications.
Could you please elaborate the below  Questions

4. How to turn single thread into multiple threaded program.
A. Depends on the program. Can be very easy, or near impossible to get right.

5. What are the factors that decide the speed of the thread ?
A. Same factors that decide the speed of other software: The hardware used. The kernel has some influence too, but not much.

For Q5, does global/local variables have any impact on the speed.

One more doubt is
10. I read that threads will store its own registers set for each of the threads. As the hard ware register set is only one, when thread switching happens do they pushed into the stack specific to the thread ?

Offline

#4 2007-07-12 01:38 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: understanding threads

If you want to convert a single threaded application into a multithreaded one, the hard part is deciding which parts should run in seperate threads. Which parts that are depends on the program. A big deciding factor is why you want to multithread the program, if you know that, it shouldn't be too hard to decide how to chop up the app. If you're lucky, the program is designed well and converting it is easy, but more often you need to restructure it a lot so it's suitable at all. After that it's a matter of adding the thread handling and locking stuff.

For 5, I suspect you want to hear something about scalability or something? The reason why a program using e.g. two threads on a SMP system isn't twice as fast as the single threaded one is mostly because of memory used by both threads at more or less the same time. When that happens everything is slowed down because of the need for locking and because the modified memory needs to be shuffled between the two CPUs. If the application isn't fully CPU bound the performance increase will be probably also less because if you're waiting for e.g. one slow harddisk multithreading won't speed it up (same for one network card, videocard, or any other single device).

So with that in mind, it doesn't matter if variables are global or local, it matters by how many threads they're accessed (or can be accesses).

10. Tell you something, it's worse than that: The same is true for each function call. Or in other words, it's optimised to death already, so most CPUs have lots of (shadow) hardware register sets, though it looks like one. So don't worry about it, it's way more low level than threads are.

Also don't worry about the speed of thread switching, because if you need to, your design is wrong. The point of using multiple threads is to use the available hardware better, not to juggle threads around. When lots of switches happen anyway it means the threads are synchronizing with eachother and waiting on eachother all the time, meaning that the whole thing degrades to a badly written single threaded synchronous program.

Offline

Board footer

Powered by FluxBB