Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Syncronization Question  (Read 1598 times)
0 Members and 1 Guest are viewing this topic.
Offline Pops

Senior Newbie




I love YaBB 1G - SP1!


« Posted 2003-01-28 19:18:22 »

Got a question I hope someone can answer for me (and tell me "bad idea" if that's the answer)...
1  
2  
3  
4  
5  
6  
7  
8  
SomeObject myObject;

syncronized(myObject) {
     ...stuff...
      if(somecondition) myObject = new SomeObject();
      ...more stuff..
      myObject.methodthis(blah);
}


I'm pretty sure there are all sorts of race issues with creating a new version of the 'locked' object within a sync block like this.  Can someone tell me for sure (or not) that this won't stand up under a highly threaded environment...
Offline William

Junior Member




No Exit


« Reply #1 - Posted 2003-01-28 20:33:01 »

Synchronization is done on objects, not on references to objects. If one thread synchronizes on the object that your myObject reference originally references and then makes myObject reference a new object, a second thread may be able to enter the synchronized block before the first thread has left the block since the second thread may synchronize on the new object that was assigned to the myObject reference by the first thread.

The risk of instruction reordering and caching issues inside the synchronized block probably also means that you can not be sure that the first thread has been able to execute anything inside the synchronized block before the second thread enters. In other words, you can probably not assume that your first line called '...stuff...' has been executed, nor that the newly created SomeObject has been fully initialized in its constructor, even though it may seem (from a single-threaded perspective) like those things would have had to happen before the second thread could enter the block.

I guess there is no rule in Java that prevents VMs from crashing in this situation since a VM could theoreticly do the reference assignment before it has initialized the new object enough for it to be able to handle synchronization. The exact behaviour is quite OS and hardware specific though.
Offline Pops

Senior Newbie




I love YaBB 1G - SP1!


« Reply #2 - Posted 2003-01-31 18:52:12 »

Thank you for the response - that goes along with what I was thinking also...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Inconnu

Junior Newbie




Java games rock!


« Reply #3 - Posted 2003-03-11 16:07:32 »

Won't you get a null pointer if your trying to synchronize on a null pointer myObject?  When it attemps to grab the monitor for myObject.. well.. there isn't one yet!  

But... even if myObject was initialized to some value.. its bad bad idea to change what your pointer points to while inside of yoru synchronize block.

It'll work.. but its a bitch and a half to debug later on!
Offline elias

Senior Member





« Reply #4 - Posted 2003-03-11 17:23:23 »

The JVM docs clearly states that every java type except 64 bit long and doubles, but including references are atomic. That is, if a thread assigns a value to a reference or a native type, another thread reading it will either get the old value (e.g. null) or the new value written by the first thread, but never a garbled value. That means that the jvm won't ever be allowed to "crash", only throw a NullPointerException or similar.

- elias

Offline coilcore

Senior Newbie




Java games rock!


« Reply #5 - Posted 2003-03-18 23:51:11 »

As a purely hypothetical situation this would work (assuming myObject was intialized), but could create very strange situations.

The monitor will be on the original object, not the new object, therefore locks can occur on the new object just as if there was no lock.  One would assume the reason for the lock was to prevent concurrent mutation of the object but that is not accomplished.  Its conceivable that the object is locked by a second thread while a first thread is still in the synchronized block, which creates a race condition I've never really considered.

But beyond the theoretical question, obfuscating code, and the potential problems, there doesn't seem to be any particullar efficency gained by taking this approach.  
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (10 views)
2014-07-30 21:08:39

Riven (21 views)
2014-07-29 18:09:19

Riven (14 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (32 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (29 views)
2014-07-23 21:07:15

Riven (30 views)
2014-07-23 20:56:16
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!