From the Operating System perspective, why is it that User Level Threads can block the entire process on a system call? If this is the case it can be useless to use them.
md.j.nasir 0 Newbie Poster
Rashakil Fol 978 Super Senior Demiposter Team Colleague
Ask yourself how user threads are implemented, and the answer reveals itself...
md.j.nasir 0 Newbie Poster
Thanks for your concern to write something, but can someone please put some light on the concept...
Rashakil Fol 978 Super Senior Demiposter Team Colleague
If you understand how user level threads are implemented, you'll know the answer to your question. If you don't understand that, then you're just memorizing sets of discrete facts. Which would be retarded.
md.j.nasir 0 Newbie Poster
A thread is a light weight process which is the smallest unit that is executed and scheduled independently by the OS.
A user level thread is created in the user area. All the threads that we create using Java library or C#(on .NET) library are user level thread. The user level threads are mapped to kernel level threads to be executed. Ultimately its the kernel level threads that are scheduled.
Now coming to my doubt :-
1. A user level thread can block the entire process on a system call. What does this mean.
2. Can kernel level threads be ever blocked???
3. Moreover, most OSs like Windows 95,98,2000,NT,XP and most Linux versions implement the one-to-one mapping of Kernel level threads to user level threads, if this is the case why to we need the whole concept of separating user level threads and kernel level threads. Ultimatel you create a user level thread which is absorbed into a kernel level thread and this thread is scheduled.....
Now please throw some light on the concept.
Rashakil Fol 978 Super Senior Demiposter Team Colleague
All the threads that we create using Java library or C#(on .NET) library are user level thread.
Aha! Now you've made the question more interesting.
1. A user level thread can block the entire process on a system call. What does this mean.
When you make certain kinds of system call (the blocking kind), you end up blocking the kernel-level thread your code is running in. Other kernel-level threads are not blocked. If your process only has one kernel-level thread and is managing its own threads, control isn't going to return to the program's thread until the system call finishes. So it has no opportunity to switch which user-level thread is running.
On the other hand, you could have a mix of user-level and kernel-level threads, where the scheduler runs in a kernel-level thread of its own and user-level threads run in the other kernel-level threads. Then if a user-level thread makes a blocking system call, the scheduler can still resurrect other user-level threads inside a separate kernel-level thread, preventing user-level threads from actually blocking the process.
If the JVM and .NET use user-level threads in their implementations, well, remember that C# and Java programs compile to bytecode and cannot unpredictably make system calls. So the interpreters will use different schemes, like translating all blocking system calls into nonblocking versions, and doing I/O from a separate kernel-level thread, to avoid blocking the other user-level threads they have running.
2. Can kernel level threads be ever blocked???
Yes, that's what happens when they make a blocking system call.
3. Moreover, most OSs like Windows 95,98,2000,NT,XP and most Linux versions implement the one-to-one mapping of Kernel level threads to user level threads, if this is the case why to we need the whole concept of separating user level threads and kernel level threads.
User-level threads have less overhead when switching between them. You can get a good performance increase, especially when running lots and lots and lots of threads.
Be a part of the DaniWeb community
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.