java threads context switching
in [Java Programming]
|
From: Ethan on 29 Jun 2010 21:01 This is regarding java threads context switching. Is there a special thread in JVM which is responsible for context switch of user java threads or does each java thread have a corresponding pthread and the scheduling is left to the underlying OS's scheduler? TIA.
From: Mike Schilling on 29 Jun 2010 21:25 "Ethan" <sam_cit(a)yahoo.co.in> wrote in message news:e04adb13-ae97-4182-97bb-e41a2fc952a6(a)z34g2000pro.googlegroups.com... > > This is regarding java threads context switching. Is there a special > thread in JVM which is responsible for context switch of user java > threads or does each java thread have a corresponding pthread and the > scheduling is left to the underlying OS's scheduler? TIA. That's an implementation question and the answer will be different for different JVMs. Having said that, all the modern JVMs I know of use native OS threads.
From: Arne Vajhøj on 29 Jun 2010 22:23 On 29-06-2010 21:01, Ethan wrote: > This is regarding java threads context switching. Is there a special > thread in JVM which is responsible for context switch of user java > threads or does each java thread have a corresponding pthread and the > scheduling is left to the underlying OS's scheduler? TIA. Java threads ca be implemented as system threads or green threads. Systems threads is scheduled by the OS. Green threads is managed by the JVM. I doubt that it would use a special thread for that. It can't really do much. All common JVM's use system threads today. Arne
From: Kevin McMurtrie on 30 Jun 2010 00:36 In article <i0e6df$lom$1(a)news.eternal-september.org>, "Mike Schilling" <mscottschilling(a)hotmail.com> wrote: > "Ethan" <sam_cit(a)yahoo.co.in> wrote in message > news:e04adb13-ae97-4182-97bb-e41a2fc952a6(a)z34g2000pro.googlegroups.com... > > > > This is regarding java threads context switching. Is there a special > > thread in JVM which is responsible for context switch of user java > > threads or does each java thread have a corresponding pthread and the > > scheduling is left to the underlying OS's scheduler? TIA. > > That's an implementation question and the answer will be different for > different JVMs. Having said that, all the modern JVMs I know of use native > OS threads. There's also the "M:N threading model" where a large number of Java threads are backed by a smaller number of native threads. It offers performance that's almost as good as native threads but it reduces the kernel overhead of each thread. The downside is that system calls which suspend native threads can lead to poor performance and deadlocks. Older OSes ran this way because their native threads were too costly to support Java's model of blocking I/O. -- I won't see Google Groups replies because I must filter them as spam
From: Arne Vajhøj on 30 Jun 2010 20:12
On 30-06-2010 00:36, Kevin McMurtrie wrote: > In article<i0e6df$lom$1(a)news.eternal-september.org>, > "Mike Schilling"<mscottschilling(a)hotmail.com> wrote: >> "Ethan"<sam_cit(a)yahoo.co.in> wrote in message >> news:e04adb13-ae97-4182-97bb-e41a2fc952a6(a)z34g2000pro.googlegroups.com... >>> This is regarding java threads context switching. Is there a special >>> thread in JVM which is responsible for context switch of user java >>> threads or does each java thread have a corresponding pthread and the >>> scheduling is left to the underlying OS's scheduler? TIA. >> >> That's an implementation question and the answer will be different for >> different JVMs. Having said that, all the modern JVMs I know of use native >> OS threads. > > There's also the "M:N threading model" where a large number of Java > threads are backed by a smaller number of native threads. It offers > performance that's almost as good as native threads but it reduces the > kernel overhead of each thread. The downside is that system calls which > suspend native threads can lead to poor performance and deadlocks. > > Older OSes ran this way because their native threads were too costly to > support Java's model of blocking I/O. I thought it was primarily JRockIt before being acquired by BEA that used this model and that the purpose was to work with more threads. Arne |