Several Question About Multi-Tasks & Multi-Threads! C/C++ under Windows OS.

Just answer what you know! Please make it clear and in 3 years old language cause i'm very new to this....Internet is the only source i got, i do not have any tutor to get back to. so do not put me down :-/

Pleas look at the numbered questions Q#. The questions are based on the above quotes.

What kind of "context information" required by processes and threads?

for sake of simplicitly, i can say the thread context includes the thread's set of machine registers, the kernel stack, etc...

process context has a virtual address space, executable code, open handles to system objects, a security context, a unique process identifier, environment variables, etc


Q1. Is what i have mentioned above is right?

Q2. What is Base Priority - Is it the first thread?

Threads are scheduled to run based on their scheduling priority. Each thread is assigned a scheduling priority. The priority levels range from zero (lowest priority) to 31 (highest priority).
***Only the zero-page thread can have a priority of zero. (The zero-page thread is a system thread responsible for zeroing any free pages when there are no other threads that need to run.)***

Q3. Is this zero-page thread is created immediately after the process is created?

The system treats all threads with the same priority as equal. The system assigns time slices in a round-robin fashion to all threads with the highest priority.

Q4. These two sentences contradicts itself!
The system treats all threads with the same priority as equal. Ok
The system assigns time slices in a round-robin fashion to all threads with the highest priority. Now what? Isn't this a contradiction?


If none of these threads are ready to run, the system assigns time slices in a round-robin fashion to all threads with the next highest priority.

Q5. I do not get it! threads always are ready to run. If an application that has multi-threads capability and you run one activity, the other ones are always ready to run! All you have to do is click it. Can you explain the quote please?

If a higher-priority thread becomes available to run, the system rejects to execute the lower-priority thread (without allowing it to finish using its time slice), and assigns a full time slice to the higher-priority thread.

Q6. So the process will only run one thread at a time since its after the highest priority thread only! Can you clarify please

Round-robin (RR) is one of the simplest scheduling algorithms for processes in an operating system, which assigns time slices to each process in equal portions and in order, handling all processes without priority.

Q7. round-robin algorithm handles all process without priority. In quote of Q4, it says The system assigns time slices in a round-robin fashion to all threads with the highest priority.

The scheduler maintains a queue of executable threads for each priority level. These are known as ready threads. When a processor becomes available, the system performs a context switch.

Q8. "These are known as ready threads". What are the not ready threads? Can you give an example of situation for a real life application please?

Q9. "When a processor becomes available, the system performs a context switch." Does this mean when the user creates new activity (thread) on the same application by clicking on the mouse on the activity?

Context switching takes the highest priority queue that contains ready threads.

Q10. Since we are using queue. Context switching happens on the front thread. What if a highest priority is in the middle of the queue. How this is going to be dealt?

Each process is started with a single thread, often called the primary thread, but can create additional threads from any of its threads.

Q11. Is primary thread here refers to the application itself without having it run anything?
For example, a program executes which creates a process (application itself), Is it a the same time called primary thread? Or primary thread is the first activity that happens on the process?


Can you please explain it in a plain English language, because i always get confused in concepts of threads, children, parents, etc....

I'm looking forward to hearing from you!
You may be better off checking your answer againt the information given here:
http://msdn.microsoft.com/en-us/library/ms684841(VS.85).aspx


Edit:
Although reading through your question - it looks like you were reading
MSDN when you came up with your questions. :-)
Last edited on
Ok i will double it check it...
#1. Context means within the thread. Thread specific storage, registers, variables etc.

#2. Base Priority will be somewhere in the middle (Average/Normal). This is OS Specific

#3. It's created @ boot time by the system. Not something you work with.

#4. Higher Priority threads either get longer time slices, or have more than 1 check within the round robin circuit.

#5. Threads are not always ready to run. Also, you don't click on a thread. It's not something you can touch or see.

#6 RR by itself has no knowledge of priorities. There must be another scheduler working with the RR to provide it with information. That quote refers to priority-less threads.

#7 This is not a question

#8 Sleep, Wait, Finished are not-Ready threads. Often you will sleep a thread or Wait one to sync it with another thread.

#9 Context-Switch means it'll load the register values, variable information, stack etc for that Thread to run on the CPU.

#10 Each queue has all the same priority threads. e.g a queue with high priority threads. So likely, the round robin works on 1 queue at a time starting with highest priority and working downwards when there are no high priority ones to execute (e.g none in Ready state).

#11 When you create an application. It runs within it's own base thread. Every application has atleast 1 thread. When the base thread terminates. All child-threads are destroyed and the application terminate.


IMO. Multi-threaded development is exponentially harder than normal application development. And harder again when you move into inter-process communication to have applications spanning across CPUs. Unless you have a serious need to get into multi-threaded development, and your already a competent developer it's something I would leave learning until your more advanced.

Mistakes are much more brutal, and debugging/profiling is alot harder into multi-thread space. Trust me on this one :)

HTH. I've tried to make my explanations as simple as possible.
Last edited on
I must agree with PP, also I must add that it is not only improvements you get when you do multi-threading, threads are quite system heavy so you do not necessarily gain that much in performance. In order to get good performance you need to take it to another level by doing things like .NET does like thread pools and such, the more you poke around in it, the more complex it gets.

Threads look cool in the beginning and simple but it is like an iceberg, seems small but there is a whole lot you don't see.
Now, you guys ROCK!
Zaita is an active member :-)
I must agree with PP, also I must add that it is not only improvements you get when you do multi-threading, threads are quite system heavy so you do not necessarily gain that much in performance. In order to get good performance you need to take it to another level by doing things like .NET does like thread pools and such, the more you poke around in it, the more complex it gets.


I think I would change that. Performance improvement has nothing to do with system implementation. It really comes down to how parallel the problem is you are trying to solve. If the problem is completely un-parallel then using multi-threading is going to offer no advantage regardless of implementation method. However, if the problem is easily paralleled then you pick the best method of threading to take advantage of that.

If you work out the optimum number of threads is going to be 2-3 and most systems running this will be dual or quad core, then thread-pooling is an extra complexity that offers no advantage.

However, if you have a problem that can be scaled to N threads with reliable gains then an implementation like round-robin or thread-pooling would be ideal.

You've just gotta remember. There is a significant amount of overhead required to create, run and maintain threads. So you don't wanna create 100 threads just to do a for-loop etc. Running time will increase dramatically.
Last edited on
Topic archived. No new replies allowed.