Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (480)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (547)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  double-checked locking... in the JDK core?!  (Read 6065 times)
0 Members and 1 Guest are viewing this topic.
Offline Roquen
« Reply #30 - Posted 2012-09-05 12:17:06 »

@Riven: exactly that thought, but as noted put/get field/static instead.  I want to think that it was always illegal from the verifiers standpoint, but not a mandated illegal transform (but heck I might be misremembering).

WRT: volatile.  Err, I don't think that volatile changes anything in this case.

Quote
And unfortunately, and very occasionally, necessary.
Why's that?  private constructor, externally visible creation method which calls constructor, makes the reference and return the new instance...done.  That seems to cover all bases.
Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #31 - Posted 2012-09-05 12:32:29 »

Volatile just guarantees that operations on it are atomic, and that all threads will eventually see changes to it. IIRC it does not give any guarantees about order. You must use locks for that.

In fact if we are talking about access to a variable across threads, then well shouldn't locks be used anyway?

Unless you use static blocks.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline nsigma
« Reply #32 - Posted 2012-09-05 12:38:25 »

WRT: volatile.  Err, I don't think that volatile changes anything in this case.

Read the article I posted above, or at least the bit about the new memory model near the bottom under Fixing Double-Checked Locking using Volatile - http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html  Assuming the list of people signing that paper is accurate, that seems pretty definitive!  Wink

Seems not to be required if the object being created is immutable with all final fields though.

Quote
And unfortunately, and very occasionally, necessary.
Why's that?  private constructor, externally visible creation method which calls constructor, makes the reference and return the new instance...done.  That seems to cover all bases.

Actually, that's what I do most of the time.  I think the situation I'm thinking of was with an abstract superclass constructor, but even then I think you're right - there are better ways!  And it's OT.  Smiley

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #33 - Posted 2012-09-05 12:59:28 »

@delt0r: as of the second memory model, volatile reads & writes are memory barriers (someone correct me if I'm wrong here)

@nsigma: we're talking about two different things at once.  volatile doesn't impact my 'x = constructor' statement. 

WRT: double checked locking...we can all just say no.  Initialization on demand is easier to write anyway.
Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #34 - Posted 2012-09-05 13:10:40 »

@Roquen 

My understanding with the new memory model is that single thread access to a volatile is strictly  in order, but no guarantees between (under the old it gave you atomic operations). That was not my understanding of memory barriers. Also i only ever properly learnt the old memory model (some company wanted me java certified!)

But then again... its been a while since i did any of this stuff outside Java. And these days with java.util.concurrent.*, there is not much more I need.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline nsigma
« Reply #35 - Posted 2012-09-05 14:01:53 »

volatile doesn't impact my 'x = constructor' statement.

If by which you mean the statement that -

The constructor is insured to be completed before the value of 'x' changes.

Then I can point you to any number of references that volatile has an affect on this (stopping out-of-order instructions being visible to another thread), as does whether the fields of the constructed object are final or not.  Strengthening the semantics of volatile and final would seem to be a major part of the new memory model.

WRT: double checked locking...we can all just say no.  Initialization on demand is easier to write anyway.

Absolutely, but as a purely theoretical concurrency masturbation thread this is quite interesting!  Smiley

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline Roquen
« Reply #36 - Posted 2012-09-05 14:19:23 »

@delt0r: yes indeed.  I can't recall the last time I wrote synchronized nor volatile.

@nsigma: In the sense that (assuming I'm not wrong) that volatile is a memory barrier, then yeah it changes things...but what I'm attempting to say is that 'x' doesn't need to be volatile to insure correctness (again that x is only set after the constructor is complete).
Offline nsigma
« Reply #37 - Posted 2012-09-05 14:32:18 »

but what I'm attempting to say is that 'x' doesn't need to be volatile to insure correctness (again that x is only set after the constructor is complete).

Not sure if we're really going around in circles saying almost the same thing here?!  Wink

What I mean is, as far as I understand it.

  • x may be assigned before the constructor is complete.
  • x doesn't need to be volatile to ensure correctness in a single thread. This is not the same as saying the value of x is not set before the constructor is completed - instructions may still be out of order but correct with regards to the creating thread.
  • Without the use of volatile another thread can see x in a half-initialized state (unless all x's fields are final). Therefore volatile ensures that the constructor is really complete prior to assignment.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline Roquen
« Reply #38 - Posted 2012-09-05 15:06:39 »

Unless I'm incorrect: no to points 1 & 3.  x may not be assigned to a field prior to completion of the constructor.  The only issue about x being volatile (other than memory barrier) is that if another thread previously read x before the assignment and re-examines it after, then it's not insured to have the up-to-date value as it's not require to re-read on each access.
Offline nsigma
« Reply #39 - Posted 2012-09-05 15:42:53 »

Unless I'm incorrect: no to points 1 & 3.  x may not be assigned to a field prior to completion of the constructor.

Check for example http://www.ibm.com/developerworks/library/j-jtp03304/

The section on initialization safety specifically talks only about final fields.

The section on volatile / double-checked locking specifically talks about how the semantics of volatile were expanded to non-volatile fields within the constructed object, and how assignment of fields within the constructor can be reordered with respect to the assignment of the object itself.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline lhkbob

JGO Knight


Medals: 32



« Reply #40 - Posted 2012-09-05 17:33:30 »

Here is an example where threads can see half-constructed instances:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
class MyReallyDumbType {
   private OtherObject dep;

   MyReallyDumbConstructor() {
      dep = new OtherObject();
      new Thread(new Runnable() {
         public void run() {
            // start modifying dep here
        }
      }
   }
}


Here, without any synchronization or volatile going on, the 2nd thread might have an inconsistent view of the memory modified by the first thread.  Although thread 1 sees dep's reference fully constructed, thread 2 might only have seen the assignment to the dep variable, and not the memory initialized by OtherObject's constructor. 

So in that rare situation, thread 2 sees a partially constructed object.

Going back to the original, bad double-checked lock in Math.random(), the problem is that the first check against the randomNumberGenerator field is not synchronized. The calling thread could see a non-null reference written by another thread that just completed initRNG() and think it doesn't need to instantiate the RNG.  Since there was no synchronization, though, the actual instance might be in an inconsistent state to the calling thread and all bets of correctness are off.

Pages: 1 [2]
  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.

atombrot (23 views)
2014-08-19 14:29:53

Tekkerue (22 views)
2014-08-16 11:45:27

Tekkerue (21 views)
2014-08-16 11:22:17

Tekkerue (12 views)
2014-08-16 11:20:21

Tekkerue (19 views)
2014-08-16 11:12:11

Rayexar (57 views)
2014-08-11 07:49:23

BurntPizza (37 views)
2014-08-10 02:09:32

BurntPizza (29 views)
2014-08-08 07:01:56

Norakomi (36 views)
2014-08-07 00:49:38

BurntPizza (66 views)
2014-08-03 07:57:17
List of Learning Resources
by Longor1996
2014-08-16 15:40:00

List of Learning Resources
by SilverTiger
2014-08-06 00:33:27

Resources for WIP games
by CogWheelz
2014-08-01 21:20:17

Resources for WIP games
by CogWheelz
2014-08-01 21:19:50

List of Learning Resources
by SilverTiger
2014-07-31 21:29:50

List of Learning Resources
by SilverTiger
2014-07-31 21:26:06

List of Learning Resources
by SilverTiger
2014-07-31 16:54:12

HotSpot Options
by dleskov
2014-07-08 06:59:08
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!