edited by
27,421 views
53 votes
53 votes

Consider the following statements with respect to user-level threads and kernel-supported threads

  1. context switch is faster with kernel-supported threads

  2. for user-level threads, a system call can block the entire process

  3. Kernel supported threads can be scheduled independently

  4. User level threads are transparent to the kernel

Which of the above statements are true?

  1. (II), (III) and (IV) only
  2. (II) and (III) only
  3. (I) and (III) only
  4. (I) and (II) only
edited by

4 Answers

Best answer
81 votes
81 votes

Answer: (A)

  1. User level thread switching is faster than kernel level switching. So, (I) is false.
  2. is true.
  3. is true.
  4. User level threads are transparent to the kernel
    In case of Computing transparent means functioning without being aware. In our case user level threads are functioning without kernel being aware about them. So (IV) is actually correct. 
edited by
39 votes
39 votes

User level threads can switch almost as fast as a procedure call. Kernel supported threads switch much slower. So, I is false. 

II, III and IV are TRUE. So A. 

"The kernel knows nothing about user-level threads and manages them as if they were single-threaded processes"

Ref: http://stackoverflow.com/questions/15983872/difference-between-user-level-and-kernel-supported-threads

16 votes
16 votes

Threads are independent subsets of processes.

There can be two types of threads:-

  1. User-level threads
  2. Kernel-level threads

When the threading is done at user-level, kernel isn't aware of it. Because Kernel just has the process table. It knows what the processes are in Main Memory; it has no thread table. The thread table is managed independently by the process. (Statement IV is True)

User-level threading can be done even when the OS doesn't support it, because OS has practically no role to play.

Since the thread table is managed independently by its process, context-switching is faster in user-level threads, as we don't have to inform the kernel. (Statement I is False)

Now since kernel is unaware of threading at the user-level, when a thread makes a system call, kernel sees it as the process making a system call. So, the whole process gets blocked, and not just the thread. (Statement II is True)

 

When the threading is done at kernel level, Kernel has the thread table. So, threads can be scheduled independently by the kernel. (Statement III is True)

Moreover, since each thread has to be registered in the kernel's thread table, context switching of threads in slower in kernel-level threads. But the plus point is that they can be scheduled independently, and when a kernel-level thread makes a system call, just the thread is blocked, and not the whole process.

edited by
1 votes
1 votes
The Option (IV)
Transparency can never mean hidden, laws of our constitution is transparent, we need to maintain transparency in the workplace, these all indicates being open to (visible) Someone being transparent means having no secrets, it’s basic English. Either option (IV) is wrong or they may mean it this way:

“User level threads are transparent to the kernel initially” – False

“User level threads are transparent to the kernel once they get into execution” – True
On a long run statement is true, if a thread comes to execution it will no longer be invisible to kernel, but it need not be true always, tough.
Answer:

Related questions

40 votes
40 votes
6 answers
1
23 votes
23 votes
3 answers
3
Kathleen asked Sep 18, 2014
12,469 views
Consider the following set of processes, with the arrival times and the CPU-burst times gives in milliseconds.$$\small \begin{array}{|c|c|c|} \hline \textbf{Process} & \t...
66 votes
66 votes
9 answers
4
Kathleen asked Sep 18, 2014
23,662 views
The minimum number of page frames that must be allocated to a running process in a virtual memory environment is determined bythe instruction set architecturepage sizenum...