1

For example, let us assume that in my operating system a context switch to another process occurs after 100μ of execution time. Furthermore, my computer has only one processor with one thread of execution possible.

If I have Process A which contains only one thread of execution and Process B which has four threads of execution, will this mean that the thread in process A will run for 100μ and process B will also run for 100μ but split the execution time between each thread before context switching?

Process A: ran for 100μ

  • Thread 1 in Process A execution time: 100μ

Process B: ran for 100μ

  • Thread 1 in Process A execution time: ~25μ

  • Thread 2 in Process A execution time: ~25μ

  • Thread 3 in Process A execution time: ~25μ

  • Thread 4 in Process A execution time: ~25μ

Would the above be correct?

Moreover, would this be different if I had a quad core processor? If I had a quad core processor, would this potentially mean each thread could run for 100μ each across all processors?

Steven K
  • 441
  • 6
  • 14
  • What are the process's priorities set in the scheduler and what kind of scheduling algorithm does the hypothetical computer and hypothetical operating system use? – xmojmr Jan 18 '15 at 07:22
  • 1
    What if we assumed round robin and there were no priorities. – Steven K Jan 18 '15 at 08:24
  • 1
    Does the hypothetical operating system schedule processes or threads (like [Windows](http://msdn.microsoft.com/en-us/library/windows/desktop/ms685096(v=vs.85).aspx) or [Linux](http://stackoverflow.com/a/15601235/2626313)) ? – xmojmr Jan 18 '15 at 10:51
  • Did not know there was a difference. Could you give a short hypothetical answer for both? – Steven K Jan 18 '15 at 16:18
  • 1
    If threads are the scheduling unit then there will be 5 threads receiving 100μ slices each as answered by @lev-kuznetsov. If processes are the scheduling unit then the scheduler can decide to be fair and split the time quantum as suggested in your question. I'm trying to figure out what are you looking for and where is the practical useful answerable [on-topic](http://stackoverflow.com/help/on-topic) problem hidden. Try to search & read similar questions like this one: http://stackoverflow.com/questions/26501901/explanation-regarding-multi-core-processor-vs-multiple-processors-with-single-co – xmojmr Jan 18 '15 at 17:25
  • 1
    To add onto this, I found this quote as well, ["A traditional, non-multithreaded operating system scheduled processes. A thread-aware operating system schedules threads, not processes. In the case where a process has just one thread, there is no difference between the two."](https://www.cs.rutgers.edu/~pxk/416/notes/05-threads.html) – Steven K Mar 21 '15 at 17:49

2 Answers2

1

It all really depends on what you are doing within the process / processing in each thread. If the process you are trying to run can benefit from splitting over threads, like for example, making calls to a web service for processing (since a web service can accept multiple calls at once and execute then separately), then no... the single thread will take longer to process than the 4 threads simply because it is executing the calls linearly instead of simultaneously.

On the other hand, if you are executing a process / code that does not benefit from thread splitting, then the time to finish all 4 processing threads will be the same on a single core.

However, in most cases, splitting the processing into threads should take less time than executing it on a single thread, if you do it right.

The matter of Cores doesn't factor in in this case unless you are attempting to run more threads than one core can handle. In which case, the OS will run the extra threads on a separate core.

This link explains a bit more the situation with Cores and Hyper-Threading... http://www.howtogeek.com/194756/cpu-basics-multiple-cpus-cores-and-hyper-threading-explained/

MaxOvrdrv
  • 1,780
  • 17
  • 32
0

Thread switches are always on the same interval regardless of process ownership. So if it's 100micro then it's always 100micro. Unless of course the thread itself surrenders execution. When this thread is going to run again is where things get complicated

Lev Kuznetsov
  • 3,520
  • 5
  • 20
  • 33
  • Thanks Lev. Sorry to ask this but could you elaborate just a little on "When this thread is going to run again is where things get complicated". Would this be because some schedulers treat processes with more threads differently than those which do not? – Steven K Jan 19 '15 at 02:18
  • 1
    When a context will get scheduled to run again will depend on untold number of factors like nice value of the process, if the process has focus on the window server and so on. To your question on whether the scheduler is fair to a process regardless of the number of threads it launches, I really don't know but I would be surprised if that would play a big role in when a context will get scheduled again. – Lev Kuznetsov Jan 19 '15 at 03:59