GATE CSE 2004 | Question: 11

Question

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?

• A. (II), (III) and (IV) only
• B. (II) and (III) only
• C. (I) and (III) only
• D. (I) and (II) only

Comments

NOTE: "Transparent" in networking and systems means invisible.

The correct answer is A. (II), (III) and (IV) only.

1. SI is False:
   Context switching is faster in user-level threads because it happens entirely in user space without requiring kernel intervention or mode switches.
2. S II is True:
   Since the kernel is unaware of individual user-level threads, a blocking system call made by one thread will cause the kernel to block the entire process.
3. S III is True:
   The kernel manages and schedules kernel-level threads directly, allowing them to be scheduled independently across multiple CPU cores.
4. S IV is True: User-level threads are completely invisible (transparent) to the kernel, which only recognizes the parent process.

---

i thought only 2 and 3 are correct. but after going through the explanation of option 4, it makes sense now.

---

thanks man @om_30

Answer 1

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. 

Comments

@akash.dinkar12

but user level threads can't scheduled independently.

E.g A user process threads a,b,c if b get block then a,c will also be blocked hence process get blocked

am i right?

---

@Abhisek Tiwari 4

right

---

so is the meaning of ‘independent’ and ‘transparent’ the same in this question’s context?

Answer 2

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

Comments

@Anirudh @Kapilp @Arjun sir, Are the following transparent to OS $\Rightarrow$

1. Secondary Memory
2. Hardware
3. Cache Memory

---

@Arjun Sir Please comment on above querry.

---

1) when process request for I/O.Then it is the responsibility of OS to allocate the appropriate I/O devices to process.All external devices are controlled by kernel through device drivers.So we can say that secondary memory is not transparent to the OS.

2)OS has full access to all hardware devices and same for the above reason it can not be transparent to the OS.

3)Cache is part of the CPU.and I think Cache can work without being aware of OS.So, it is transparent to the OS.

---

then how cache is allocated for hit and miss??

and whom it is not transparent???

---

 Arjun sir 

case 1:

context switch between user mode -user mode is more than user mode-kernel mode, becoz context switch only occur in kernel mode then for user-user we have to first switch in kernal and save all pcb ,register.but for user -kernel we only need system call

case 2:now

context switch time is less in user level thread .

I am not getting why this is less for user level thread ?

.

---

context switch time is less in user level thread .

I am not getting why this is less for user level thread ?

Creating a new thread, switching between threads, and synchronizing threads are done via procedure call. i.e no kernel involvement. 

On the other hand, for kernel level thread, there's always kernel involved which eventually slows down the switch.

---

 Neelay my both cases are contradicts to each other thts why m saying why less ?

---

they are not contradicting, the first case is correct, as context switch between two user processes involves

Switching to kernel mode + Saving the context

And to switch to kernel mode, its about setting the $mode$ bit to $1$

And for the second case I gave you the reason, there's no kernel involvement as such. And this is in comparison to kernel level threads. So don't confuse with processes and threads!

---

thnks a lot :)

now got my mistake .i am considering process instead of thread.

thnks again

---

User-level threads implement in user-level libraries, rather than via systems calls, so thread switching does not need to call operating system and to cause interrupt to the kernel. In fact, the kernel knows nothing about user-level threads and manages them as if they were single-threaded processes.

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

---

because when user level thread calls for system call then it need to switch to kernal mode which can block the entire process

---

kernel doesnt know about user level threads right? so how d can be true as transperent means that kernel can see

---

@viral8702 I’m transparent to you means you cannot see me.

---

okay sir

---

Very much contrary to normal english

---

Sorry sir but transparent means clear to see through opaque is the the word used to  say for something we can't see through.

---

But that meaning doesn't apply here.

---

All of a sudden the comment section has become a Verbal Apti's One

Answer 3

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.

Comments

I found this answer to be the best. It very well explains the entire concept.

---

best answer for someone who is new to threads

---

good one.

Answer 4

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 5

option A is the correct option.

In user level threads the system calls can block the entire process.

These threads are also not recognised by the os so (iv) is correct.

Plus, kernel threads can be scheduled independently.

Answer 6

In computer science, transparency often refers to whether a component or process is visible or "apparent" to another part of the system:

 

If something is transparent, it means one part of the system doesn't need to "know about" or manage it explicitly.

For example, user-level threads are transparent to the kernel because the kernel doesn't "see" them or interact with them.