The Gateway to Computer Science Excellence
First time here? Checkout the FAQ!
+26 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
asked in Operating System by Veteran (59.9k points)
edited by | 4.9k views
What is the meaning of 4th statement?
You can say are independent of that.
why context switch is slower in kernel ?
thread switching in user /kernel mode

context switching in user/kernel mode

whts the difference between these two ?

2 Answers

+48 votes
Best answer

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

This is little confusing .if you search define transparent on google, you get definations like "(of a material or article) allowing light to pass through so that objects behind can be distinctly seen."->"transparent blue water"", "

easy to perceive or detect."->"the residents will see through any transparent attempt to buy their votes"
This makes it all confusing. Though if go & check more defination
(of a process or interface) functioning without the user being aware of its presence.
So 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. (Even though other defination of transparent disagree to it !)
answered by Boss (43.5k points)
edited by

The meaning of Transparent is what's confusing!

Once you know that it's pretty easy! check  this out!

what is the meaning of iii statement?

@Abhisek Tiwari 4

Kernel supported threads can be scheduled independently

It means if our kernel is implementing threads then he is already well aware of all the information like how many threads it has, how much time it has to give to each thread etc..So may be if some threads get blocked, it will schedule other thread during that meantime independently..



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?

+28 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"


answered by Veteran (384k points)

@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

Related questions

Quick search syntax
tags tag:apple
author user:martin
title title:apple
content content:apple
exclude -tag:apple
force match +apple
views views:100
score score:10
answers answers:2
is accepted isaccepted:true
is closed isclosed:true
47,881 questions
52,231 answers
67,650 users