(13) In the three following situations explain which model we should use: (a) us
ID: 3890321 • Letter: #
Question
(13) In the three following situations explain which model we should use: (a) user-level threading (b) kernel-level threading (c) hybrid-threading (d) no-threading (i.e. single-threaded application) Explain clearly what the advantages are to the choices you have made, or why the other options are not viable. While making your decision consider things like the amount/type of I/O your application requires. (a) You are writing an application for an operating system (that support thread- ing). The application needs to continuously and simultaneously fetch infor- mation over a network connection, accept input from the user, and format the display to the user. (b) You are writing an application for a single-threaded operating system (i.e. the OS does not support threading). The application waits for a packet of internet information, and then processes the information. The packets come once an hour, and processing takes onlv a few minutes. (c) You are writing an application to monitor a realtime system (i.e. a manufac- turing floor). The OS supports threads but not 'real-time' threads (the o.s. has no way to fulfill specific timing requests). The application needs to contin uously monitor aspects of the real-time system it is monitoring with specific requirements as to the timing. (i.e. every 5 seconds check the heat gauge). If there are N aspects of the real-time system that need to be monitored, each 'check' of that aspect may call a blocking system call.Explanation / Answer
User-Level Threads
Threads are the primary programming interface in multithreaded programming. User-level threads [User-level threads are named to distinguish them from kernel-level threads, which are the concern of systems programmers, only. Because this book is for application programmers, kernel-level threads are not discussed.] are handled in user space and avoid kernel context switching penalties. An application can have hundreds of threads and still not consume many kernel resources. How many kernel resources the application uses is largely determined by the application.
Threads are visible only from within the process, where they share all process resources like address space, open files, and so on. The following state is unique to each thread.
Thread ID
Register state (including PC and stack pointer)
Stack
Signal mask
Priority
Thread-private storage
Because threads share the process
Kernel-Level Threads
To make concurrency cheaper, the execution aspect of process is separated out into threads. As such, the OS now manages threads and processes. All thread operations are implemented in the kernel and the OS schedules all threads in the system. OS managed threads are called kernel-level threads or light weight processes.
In this method, the kernel knows about and manages the threads. No runtime system is needed in this case. Instead of thread table in each process, the kernel has a thread table that keeps track of all threads in the system. In addition, the kernel also maintains the traditional process table to keep track of processes. Operating Systems kernel provides system call to create and manage threads.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.