• 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

Is a single Java statement Atomic ?

 
Ranch Hand
Posts: 316
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello savvy pals,

Assertion :- Any java statement would ultimately be converted into Assembly language code (or Machine code finally) before it is executed. Moreover any java statement when converted would generally be translated into many Assembly language statements. i.e. 1 HLL statement == Many Assembly lang statmets. Knowing this....

Problem:- Is a single java statement atomic ???

if the answer to above question is Yess then

Asserion2 :- any looping or conditional construct is a java statement.

Problem2 :- But we need to synchronize a code having just one for loop. ???


Thanks !!!

 
Bartender
Posts: 6663
5
MyEclipse IDE Firefox Browser Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Most operations are indeed atomic. Operations involving 64 bit structures like double / long are not atomic by themselves. The 64 bit operation can be split into 2 32 bit operations. It is possible to see a weird result when only one of them has completed

That said you will not be quizzed about this in the SCJP. Promise

Here is a reference to the problem -> http://java.sun.com/docs/books/jls/third_edition/html/memory.html

Look for "Non-atomic Treatment of double and long". You can get around it by making a long / double volatile or creating memory barriers to the main memory using the synchronized keyword
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Deepak Bala wrote:Most operations are indeed atomic. Operations involving 64 bit structures like double / long are not atomic by themselves.


This sounds as if operations on 32 bit structures were atomic, which is not the case. Something as simple as "c++" (with "c" being an int) is not atomic. See http://java.sun.com/docs/books/tutorial/essential/concurrency/interfere.html and http://java.sun.com/docs/books/tutorial/essential/concurrency/atomicvars.html for details and workarounds.
 
Deepak Bala
Bartender
Posts: 6663
5
MyEclipse IDE Firefox Browser Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for adding more clarity Ulf. I wanted to avoid mentioning classes that support Atomic operations since it might add more clutter to the OPs question.

Sahil the bottom line is that Concurrency topics for the SCJP will not try to quiz you in such detail.
 
Sahil Kapoor
Ranch Hand
Posts: 316
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@ Deepak and ulf

Thankyou so much

Atleast i got an issue to read further after SCJP !!!
 
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm speculating here, but it seems that a conditional test such
as x == y, excluding longs and doubles, would be atomic, but
any evaluations that come before would be a different atom.
Further, a context switch could occur before execution of the
first statement after the branch.

Jim ... ...
 
Deepak Bala
Bartender
Posts: 6663
5
MyEclipse IDE Firefox Browser Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jim Hoglund wrote:I'm speculating here, but it seems that a conditional test such
as x == y, excluding longs and doubles, would be atomic, but
any evaluations that come before would be a different atom.
Further, a context switch could occur before execution of the
first statement after the branch.

Jim ... ...



I am not sure I quite understood that. Are you asking if the value of x or y can change while the comparison operation takes place ? Or are you saying the result of the comparison operation is assigned atomically.

but any evaluations that come before would be a different atom



Did you mean a different transaction ?
 
Jim Hoglund
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm thinking that x and/or y could be the result of evaluating an expression and
these evaluations would not be atomic with the equality compare. Then x == y
is atomic but assigning its result, or branching on its result, would be interruptable.
Does this make sense?

Jim ... ...
 
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with the above posts by Jim And Ulf. Going back to the original post I would add:

Sahil Kapoor wrote:Problem:- Is a single java statement atomic ???


In general, no. Some are, but many are not. You should never assume that a statement is atomic - you should know why that particular statement is atomic, or you should assume it isn't.

Sahil Kapoor wrote:Problem2 :- But we need to synchronize a code having just one for loop. ???


Sometimes, yes - even if all the individual statements in the loop are atomic. Because if you have two or more atomic statements, stuff can still happen in between those two statements. That's why even with a Vector or Collections.synchronizedList(), you can't safely iterate the list without additional synchronization. It's pretty difficult to do anything useful with one of these without additional synchronization, really. Which is why I consider them inherently evil, as they just mislead people into thinking that they're "thread-safe" just because they're "synchronized". To use synchronization effectively, you usually need to make sure the synchronization wraps around whatever group of statements you need to be protected from interference.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic