The way to think about this is that User Threads and Kernel Threads are two completely different animals.
There is no context switch in user threads under the term's normal and customary meaning.
Both types(process Context switch and thread context switch) involve handing control over to the operating system kernel to perform the context switch(i am mainly talking about thread context switch).
I see your confusion. First of all, what is being described here only applies to Kernel Threads. Second, (and this problem is clearly the result of wording and not the overall message), in Kernel Threads, there are no "process context switches," there are only "Thread Context Switches".
In ye olde days when there were no threads, a change in scheduling meant a change in a process context. The hardware instructions to do this have names like Load Process Context and Save Process Context. But in operating system that schedule threads (kernel threads) we are left with this old terminology that is no longer very precise. (This is a problem that occurs in many places when explaining operating systems).
if T(1-a) and T(1-b) are user level threads,Kernel won't be able to distinguish T(1-a) and T(1-b),then how context switch will be done?
If they are user level threads, the kernel does not know or care about them. The switch among them is handled by a user library. The switching of "threads" is not a context switch.
won't the cost/dealy will be same as that of process context switch as not only virtual memory space gets changed but also TLB gets flushed??
Hopefully, the operating system is smart enough to know not to flush memory caches when it switches among threads in the same process.
I am convinced that academics need to abandon the kernel/user thread (and even worse, 1-to-1, many-to-1, and many-to-many [yuk]) constructs. In their place I suggest using the terms
"real threads" and "simulated threads".
