answersLogoWhite

0


Best Answer

A Java thread can be considered as similar to a user level thread. Let us say you are running a web browser, windows media player and GTalk for chat simultaneously - Actually the operating system is running an individual thread for each of these apps which gives you a seamless feeling of things running in parallel. Similarly Java Threads are features in the Java programming language that allow you to run multiple JVM tasks in parallel.

User Avatar

Wiki User

14y ago
This answer is:
User Avatar

Add your answer:

Earn +20 pts
Q: Difference between Java threads and user level thread?
Write your answer...
Submit
Still have questions?
magnify glass
imp
Continue Learning about Engineering

What are the circumstances of user level thread better than kernel level thread?

There are two distinct models of thread controls, and they are user-level threads and kernel-level threads. The thread function library to implement user-level threads usually runs on top of the system in user mode. Thus, these threads within a process are invisible to the operating system. User-level threads have extremely low overhead, and can achieve high performance in computation. However, using the blocking system calls like read(), the entire process would block. Also, the scheduling control by the thread runtime system may cause some threads to gain exclusive access to the CPU and prevent other threads from obtaining the CPU. Finally, access to multiple processors is not guaranteed since the operating system is not aware of existence of these types of threads. On the other hand, kernel-level threads will guarantee multiple processor access but the computing performance is lower than user-level threads due to load on the system. The synchronization and sharing resources among threads are still less expensive than multiple-process model, but more expensive than user-level threads. Thus, user-level thread is better than kernel level thread.


What is the difference between a Parent Process and Foreground Process?

A parent process is a process that has spawned one or more child processes such that it takes "ownership" of those processes. A foreground process typically means a process that has a user-interface as opposed to a background process which typically does not. Most background processes are services while most foreground processes are applications. It's important to note that the term "process" has a specific meaning in a multi-processing environment. A process is a computer program that has one or more threads of execution. A thread is the machine-level representation of a task and a process may instantiate as many tasks as are required (hardware permitting). All tasks share the same memory space as the process itself, however each task has its own stack for local storage, as well as to enable the thread's function call-and-return mechanism in addition to thread-local exception handling. Every process must have at least one thread of execution typically referred to as the main thread because that is the thread that executes the program's global main function (the entry point of the application) and subsequently instantiates any additional threads required by the main thread. The additional threads are usually called worker threads and any thread can instantiate its own worker threads. Unlike parent/child processes, thread's cannot "own" other threads; the threads are owned by the process. However, it is possible for worker threads to be controlled by other threads in the same process, so in that sense the controlling thread can be said to be a parent thread. When the main function returns, the main thread terminates, however any active threads within the process will continue executing, thus keeping the process "alive". In many cases this would be undesirable particularly if those threads attempt to access shared memory that is released by the main thread. So although there is no notion of ownership amongst threads, any controlling thread that must terminate before its workers have completed their tasks should signal its workers to terminate and then wait for them to terminate before terminating itself. Threads of execution within a process execute concurrently. All this means is that the operating system's task scheduler gives each thread a time-slice of the CPU to do some work, before saving the thread's state and moving onto the next thread (which may belong to another process entirely). Task-switching is so rapid that it can appear as though all threads are executing simultaneously, however that is only physically possible when the CPU has 2 or more cores available. Only one thread may execute upon any single core at any given moment. Multiple threads are typically used to maintain responsiveness. In a GUI environment, a time-consuming task would take up the entire time-slice of a process so it won't be able to respond to any messages on the message queue unless the task specifically checks the queue periodically. However, by using a worker thread to carry out the task, the controlling thread can remain responsive to messages. The message queue can also be used by threads to signal other threads, thus a controlling thread can respond to periodic progress reports from its worker threads if required. In this sense it can be said that the worker threads are background tasks, while the controlling thread is the foreground task.


The gross head in turbine installation is difference of level between?

it is difference between the water level from head race and tail race


Can the subroutines of a high level language be called processes?

No. A subroutine (also known as a procedure or function) is best thought of as being a task. The executable (program) is the actual process. Every process has at least one thread of execution and each thread has its own local call stack. Thus multiple threads may concurrently execute the same task independently of any other threads within the same process. This is useful when we have a large or time-consuming task which can be broken down or divided up into smaller instances of the same task; each thread handles a small portion of the overall task and operates concurrently with all other instances of that task. Depending on how many CPU cores we have available, multiple threads of execution should complete the whole task quicker than a single thread would have. That is, if we divide the task into four, we could potentially complete the whole task in 1/4 of the time it would take with just one thread of execution.


What is the difference between a flat roof and a pitched roof?

The angle, in comparison to "level".

Related questions

What are the advantages and disadvantages of user level threads and kernel level threads?

- USER LEVEL THREADS Aadvantages: · User-level threads can be implemented on operating system that does not support threads. · Implementing user-level threads does not require modification of operating system where everything is managed by the thread library · Simple representation which the thread is represented by a the thread ID, program counter, register, stack , all stored in user process address space · Simple management where creating new threads, switching threads and synchronization between threads can be done without intervention of the kernel · Fast and efficient where switching thread is much more inexpensive compared to a system call - Disadvantages: · There is a lack of coordination between threads and operating system kernel. A process gets one time slice no matter it has 1 thread or 10000 threads within it. It is up to the thread itself to give up the control to other threads · If one thread made a blocking system call, the entire process can be blocked in the kernel, even if other threads in the same process are in the ready state KERNEL LEVEL THREAD: - Advantages: · Because kernel has the full knowledge of all the threads, scheduler may decide to allocate more time to a process having large number of threads than process having small number of thread, where the kernel threads come useful for intense application - Disadvantages: · Kernel level threads are slow and inefficient, since kernel must manage and schedule all the threads as well as the processes. It requires a full TCB for each thread to maintain information about threads, which results in increasing of overheads and kernel complexity


Describe the action taken by a thread library to context switch between user level threads?

AnswerThe thread library function performs the following actions to context switch between user level threads:1. Copy all live registers to Thread control Block (TCB)2. Restore the state of the thread to run next i.e. (copy the values of live registers from (TCB) to registers)3. Move to the next thread to execute


What are the circumstances of user level thread better than kernel level thread?

There are two distinct models of thread controls, and they are user-level threads and kernel-level threads. The thread function library to implement user-level threads usually runs on top of the system in user mode. Thus, these threads within a process are invisible to the operating system. User-level threads have extremely low overhead, and can achieve high performance in computation. However, using the blocking system calls like read(), the entire process would block. Also, the scheduling control by the thread runtime system may cause some threads to gain exclusive access to the CPU and prevent other threads from obtaining the CPU. Finally, access to multiple processors is not guaranteed since the operating system is not aware of existence of these types of threads. On the other hand, kernel-level threads will guarantee multiple processor access but the computing performance is lower than user-level threads due to load on the system. The synchronization and sharing resources among threads are still less expensive than multiple-process model, but more expensive than user-level threads. Thus, user-level thread is better than kernel level thread.


Describe the action taken by a kernel to context switch between kernel level threads?

Context switching between kernel threads typically requires saving the value of the CPU registers from the thread being switched out and restoring the CPU registers of the new thread being scheduled.


What is the difference between Kernel and User level thread?

A kernel thread, sometimes called a LWP (Lightweight Process) is created and scheduled by the kernel. Kernel threads are often more expensive to create than user threads and the system calls to directly create kernel threads are very platform specific. A user thread is normally created by a threading library and scheduling is managed by the threading library itself (Which runs in user mode). All user threads belong to process that created them. The advantage of user threads is that they are portable. The major difference can be seen when using multiprocessor systems, user threads completely managed by the threading library can't be ran in parallel on the different CPUs, although this means they will run fine on uniprocessor systems. Since kernel threads use the kernel scheduler, different kernel threads can run on different CPUs. Many systems implement threading differently, A many-to-one threading model maps many user processes directly to one kernel thread, the kernel thread can be thought of as the main process. A one-to-one threading model maps each user thread directly to one kernel thread, this model allows parallel processing on the multiprocessor systems. Each kernel thread can be thought of as a VP (Virtual Process) which is managed by the scheduler.


Is there one stack per process when user level threads are used?

In both kernel and User level they have one stack per thread


How do threads work in an operating system?

threads are the light weight process or it is a part of the process which can execute simulteniously by sharing systm resources.... two types of thread 1.user level thread 2.kernel level thread


What takes longer a context switch with user level threads or one with kernel level threads?

Kernel level threads take a longer time to context switch since OS will have to save and reload each and every TCB (Thread Control block) where as in user level no kernel intervention threads simply context switch more efficiently. But there are disadvantages such as since OS sees the user leve threads as a whole process it will not give a large portion of CPU time for execution if a thread is blocked the whole process goes to the waiting state please correct my answer if im wrong godlovesu49@hotmail.com thanks regards yo


What are user level threads?

•No special support needed from the kernel (use any Unix) •Thread creation and context switch are fast (no syscall) •Defines its own thread model and scheduling policies


Is user level threads are transparent to kernel level threads?

user level theads are not tranparent to kernel level threads.


What is the difference between a Parent Process and Foreground Process?

A parent process is a process that has spawned one or more child processes such that it takes "ownership" of those processes. A foreground process typically means a process that has a user-interface as opposed to a background process which typically does not. Most background processes are services while most foreground processes are applications. It's important to note that the term "process" has a specific meaning in a multi-processing environment. A process is a computer program that has one or more threads of execution. A thread is the machine-level representation of a task and a process may instantiate as many tasks as are required (hardware permitting). All tasks share the same memory space as the process itself, however each task has its own stack for local storage, as well as to enable the thread's function call-and-return mechanism in addition to thread-local exception handling. Every process must have at least one thread of execution typically referred to as the main thread because that is the thread that executes the program's global main function (the entry point of the application) and subsequently instantiates any additional threads required by the main thread. The additional threads are usually called worker threads and any thread can instantiate its own worker threads. Unlike parent/child processes, thread's cannot "own" other threads; the threads are owned by the process. However, it is possible for worker threads to be controlled by other threads in the same process, so in that sense the controlling thread can be said to be a parent thread. When the main function returns, the main thread terminates, however any active threads within the process will continue executing, thus keeping the process "alive". In many cases this would be undesirable particularly if those threads attempt to access shared memory that is released by the main thread. So although there is no notion of ownership amongst threads, any controlling thread that must terminate before its workers have completed their tasks should signal its workers to terminate and then wait for them to terminate before terminating itself. Threads of execution within a process execute concurrently. All this means is that the operating system's task scheduler gives each thread a time-slice of the CPU to do some work, before saving the thread's state and moving onto the next thread (which may belong to another process entirely). Task-switching is so rapid that it can appear as though all threads are executing simultaneously, however that is only physically possible when the CPU has 2 or more cores available. Only one thread may execute upon any single core at any given moment. Multiple threads are typically used to maintain responsiveness. In a GUI environment, a time-consuming task would take up the entire time-slice of a process so it won't be able to respond to any messages on the message queue unless the task specifically checks the queue periodically. However, by using a worker thread to carry out the task, the controlling thread can remain responsive to messages. The message queue can also be used by threads to signal other threads, thus a controlling thread can respond to periodic progress reports from its worker threads if required. In this sense it can be said that the worker threads are background tasks, while the controlling thread is the foreground task.


Example for user level threads and kernel level threads?

hjhgjhgj