5.2k views

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 | 5.2k views
0
What is the meaning of 4th statement?
+2
You can say are independent of that.
0
why context switch is slower in kernel ?
0
thread switching in user /kernel mode

context switching in user/kernel mode

whts the difference between these two ?
+1

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
+3
0

The meaning of Transparent is what's confusing!

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

http://whatis.techtarget.com/definition/transparent

0
what is the meaning of iii statement?
+1

@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..

0

@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?

0

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.

+2

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

1. Secondary Memory
2. Hardware
3. Cache Memory
+1
@Arjun Sir Please comment on above querry.
+1
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.
0
then how cache is allocated for hit and miss??

and whom it is not transparent???
0

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 ?

.

0

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.

0

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

+1
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!
0
thnks a lot :)

thnks again
0
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
0
because when user level thread calls for system call then it need to switch to kernal mode which can block the entire process

1
2