1,253 views

2 Answers

1 votes
1 votes

Answer:

The register set is listed as a per-thread rather than a per-process because of the following reasons:

  • Multiprogramming threads behave in the same way as the multiprogramming processes. Due to this each thread require its own area for saving the register.
  • When a thread stops, the register has the values of the threads which is needed to be saved, just like when the process halts then the register must be saved.

 

0 votes
0 votes
Registers store the thread data that the cpu was working with. If a thread wants to start right where it was context switched earlier, it needs that temporary data also. Hence we store it on per thread basis.

Else, if we are okay with repeating the most recent instruction, then a PC register will suffice and rest registers we can remove.

Related questions

659
views
1 answers
0 votes
admin asked Oct 24, 2019
659 views
In a system with threads, is there one stack per thread or one stack per process when user-level threads are used? What about when kernel-level threads are used? Explain.
371
views
0 answers
0 votes
admin asked Oct 24, 2019
371 views
In Sec. $2.3.4$, a situation with a high-priority process, H, and a low-priority process, $L$, was described, which led to $H$ looping ... the same problem occur if round-robin scheduling is used instead of priority scheduling? Discuss.
305
views
0 answers
0 votes
admin asked Oct 24, 2019
305 views
Can the priority inversion problem discussed in Sec. $2.3.4$ happen with user-level threads? Why or why not?
1.7k
views
0 answers
0 votes
admin asked Oct 24, 2019
1,735 views
Does Peterson’s solution to the mutual-exclusion problem shown in Fig. $2-24$ work when process scheduling is preemptive? How about when it is nonpreemptive?