• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

When the scheduler can get a thread back to runnable state?

 
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If we are have such scenario:

Is it possible for the scheduler to take a thread back to runnable state in the middle of an instruction?

I was curious if such scenario is possible:
1. t1 reads the value of x(but not the whole instruction is executed)
2. Scheduler gets t1 to runnable and starts to execute t2 instead
3. t2 executes the whole run method(increases x with 10)
4. Scheduler again swaps both threads.
5. t1 already has the value of x=0(which is incorrect - t2 has changed it to 10)
6. t1 finishes the instruction and the final value of x is 10
 
Stoian Azarov
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have done some more testing and it seems that my scenario is impossible.
I hope I am not making wrong assumption
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stoian Azarov wrote:I have done some more testing and it seems that my scenario is impossible.



The JVM spec goes into a ton of detail of how atomic instructions are (along what sorts of optimizations can happen when dealing with volatile variables and synchronization blocks).

Basically, getting an int is atomic, setting an int is atomic, so.... getting the value of x to use is atomic, the line "x=10" is atomic, but "x = x + 10" which both gets and sets the variable x, is *not* atomic.

The variable x is not declared as volatile, nor is synchronization used, some optimizations, such as caching it to a register may also be used. This second case, likely doesn't have any affect, as there is no need to cache unless you intend to reused, such as in a loop.

So... it is possible to end up with the variable x with a value of 10.

Henry

 
Stoian Azarov
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Henry for your valuable response.

I will definitely read more about this topic starting from JVM specification and the info provided by you is a good start.
 
Ranch Hand
Posts: 64
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Stoian Azarov
are you run this code i got 20 as output

x is static here right ?
 
Ranch Hand
Posts: 59
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Henry Wong wrote:

Stoian Azarov wrote:I have done some more testing and it seems that my scenario is impossible.



The JVM spec goes into a ton of detail of how atomic instructions are (along what sorts of optimizations can happen when dealing with volatile variables and synchronization blocks).

Basically, getting an int is atomic, setting an int is atomic, so.... getting the value of x to use is atomic, the line "x=10" is atomic, but "x = x + 10" which both gets and sets the variable x, is *not* atomic.

The variable x is not declared as volatile, nor is synchronization used, some optimizations, such as caching it to a register may also be used. This second case, likely doesn't have any affect, as there is no need to cache unless you intend to reused, such as in a loop.

So... it is possible to end up with the variable x with a value of 10.

Henry



Hi Henry,

I believe you replied without taking into consideration the below lines of code. Isn't the output always 20 for the OP's code since the below lines do synchronize the run method.



Is my below understanding correct?

1. Since x=x+10 is a non-atomic operation, a thread say t1 might read the value of x, sent back to runnable state and then re-start from where it left
( that is increasing the last read value by 10). The other thread t2 may be done with accessing and changing x when the thread t1 was in runnable state. So, both the threads end up changing the value of x to 10.

2. If the variable x is made volatile and the things go as stated in point 1, when the thread t2 changes the variable x, the copy of x with thread t1 also changes to 10 and the value is changed to 20 by thread t1.

I don't get how "optimizations, such as caching it to a register may also be used" to sync the OP's code.

Regards,
Nitin Sethi
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic