• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Thread Switching - any special method/code it calls before a switch is made?

 
Dinesh Andavar
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Is there any method or code which the JVM calls by default before taking a thread out of the running state to say either running/blocked state???


 
Chan Ag
Rancher
Posts: 1089
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yea, I'm guessing there must be many methods JVM must call. For instance, JVM/OS has to store the values of the variables, save the thread state, update some global state variables, before the swap.

If you mean user created methods, I don't know. So I'd pass.



Edit - Hey, I must clarify one thing. I didn't mean the Java variables, when I said variables. I meant the registers and the OS variables.
For example some sort of a mechanism must tell the OS that when a thread starts running again, it must start from a particular instruction.
I meant those things when I said Thread state.
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13055
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dinesh Andavar wrote:Hi Is there any method or code which the JVM calls by default before taking a thread out of the running state to say either running/blocked state???


Nope - see the JavaDocs for java.lang.Thread for discussion of Thread life cycle.

Bill
 
Dinesh Andavar
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your feedback guys.
Would not it be great if there was a user created method that JVM would call before switching.
Do any of you guys see that as a useful feature or is it just me??!!
 
Steve Luke
Bartender
Posts: 4181
21
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dinesh Andavar wrote:Thanks for your feedback guys.
Would not it be great if there was a user created method that JVM would call before switching.
Do any of you guys see that as a useful feature or is it just me??!!


That assumes the JVM is either in control of thread switching (which usually it is not) or privy to when said switching occurs. Switching thread contexts itself is pretty darn expensive as it is, but to have it have to process a queue of tasks to execute when switching threads would be even more so - and would just delay it. Not to mention - where (what thread) would this code be executed in? Should it interrupt the normal flow of the old thread? This sounds like a scary idea to me, as it seems like it could lead to all kinds of inconsistent states.

Is there any reason you think it would be useful?
 
Henry Wong
author
Marshal
Pie
Posts: 20886
75
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steve Luke wrote:
That assumes the JVM is either in control of thread switching (which usually it is not) or privy to when said switching occurs. Switching thread contexts itself is pretty darn expensive as it is, but to have it have to process a queue of tasks to execute when switching threads would be even more so - and would just delay it. Not to mention - where (what thread) would this code be executed in? Should it interrupt the normal flow of the old thread? This sounds like a scary idea to me, as it seems like it could lead to all kinds of inconsistent states.

Is there any reason you think it would be useful?


Also, what is to prevent the application from using the callback to execute more code? ... meaning if I don't want the OS from ending my time slice, can't I just use the callback to extend it (execute what I wanted done in the original thread in the callback instead)?


Anyway, if you really want to do this, one option is to create your own scheduling system. You can have your threads do some work, and then check if it should switch out (using some sort of common state). This means that your threads are "context switch" aware -- and will cooperatively puts itself to sleep, if it decides that it's time slice is done. You can also put a call to your special method prior to the switch here, since it is your code.

The underlying OS scheduler only sees one runnable thread at a time, and doesn't know that your threads are doing cooperative user-level scheduling. It is merely running the only thread that is runnable at any given time.

Henry
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic