Threads and synchronization

Discussion in 'Java' started by Srubys@gmail.com, Jun 25, 2008.

  1. Guest

    hiya

    1. Why do all the statements in constructor execute prior to
    statement “ new Thread(this).start();” , even if “new
    Thread(this).start();” precedes the other statements? For example:

    class A {
    int i = 100;
    A(){
    new Thread( this ).start();
    i++; // i will have value of 101 before new
    thread is
    started, even though i++ follows the
    statement that creates a new thread
    }



    2. While a thread is inside a synchronized method, all other threads
    that try to call any synchronized methods on the same instance have to
    wait.

    So if for example process has 3 threads ( A, B and C) and A calls some
    synchronized method on object D, and while A is still inside D, B and
    C also call method on same object. While A is still inside D, will
    context switching still happen, even if B and C won’t do anything due
    to waiting on thread A to exit the monitor?



    3.After experimenting with a code a bit, I came to conclusion that
    when a thread enters a synchronized block, all other threads trying to
    enter synchronized block on same instance will have to wait until this
    thread exits the synchronized block. So, if we again have threads A,
    B and C and if thread A enters object’s monitor via synchronized
    block:

    synchronized( object ) {

    for( int i = 0; I < 1000000; i++ );
    }

    then A will get ahold of object’s monitor even if no methods are
    called on that object inside the synchronized block. And B and C won’t
    be able to enter synchronized block until A exits the synchronized
    block? Right?

    BTW – why does infinite for() loop inside synchronized block cause
    compile time error?



    4. If we again have threads A, B and C and if thread A enters
    object’s monitor and then calls notify(), then a thread that called
    wait() on the same object is awakened:

    • but what if B and C are trying to get ahold of object’s
    monitor, but didn’t call wait()? Will they still get notified
    via
    notify()?
    • if thread A calls wait(); but if then none of the threads that
    afterwards enter same object’s monitor ever call notify(),
    will A ever get awaken or will it always remain in a wait
    state?


    thank you
     
    , Jun 25, 2008
    #1
    1. Advertising

  2. Arne Vajhøj Guest

    wrote:
    > 1. Why do all the statements in constructor execute prior to
    > statement “ new Thread(this).start();” , even if “new
    > Thread(this).start();” precedes the other statements? For example:
    >
    > class A {
    > int i = 100;
    > A(){
    > new Thread( this ).start();
    > i++; // i will have value of 101 before new
    > thread is
    > started, even though i++ follows the
    > statement that creates a new thread
    > }


    I believe instance members are instantiated before constructor
    statements.

    And you should not use this in the constructor !

    > 2. While a thread is inside a synchronized method, all other threads
    > that try to call any synchronized methods on the same instance have to
    > wait.
    >
    > So if for example process has 3 threads ( A, B and C) and A calls some
    > synchronized method on object D, and while A is still inside D, B and
    > C also call method on same object. While A is still inside D, will
    > context switching still happen, even if B and C won’t do anything due
    > to waiting on thread A to exit the monitor?


    I think that is implementation specific.

    > 3.After experimenting with a code a bit, I came to conclusion that
    > when a thread enters a synchronized block, all other threads trying to
    > enter synchronized block on same instance will have to wait until this
    > thread exits the synchronized block. So, if we again have threads A,
    > B and C and if thread A enters object’s monitor via synchronized
    > block:
    >
    > synchronized( object ) {
    >
    > for( int i = 0; I < 1000000; i++ );
    > }
    >
    > then A will get ahold of object’s monitor even if no methods are
    > called on that object inside the synchronized block. And B and C won’t
    > be able to enter synchronized block until A exits the synchronized
    > block? Right?


    Yes.

    > 4. If we again have threads A, B and C and if thread A enters
    > object’s monitor and then calls notify(), then a thread that called
    > wait() on the same object is awakened:
    >
    > • but what if B and C are trying to get ahold of object’s
    > monitor, but didn’t call wait()? Will they still get notified
    > via
    > notify()?


    No. What should notification mean ?

    > • if thread A calls wait(); but if then none of the threads that
    > afterwards enter same object’s monitor ever call notify(),
    > will A ever get awaken or will it always remain in a wait
    > state?


    It will remain unless you the one the version with timeout.

    I think - I have never tried it.

    Arne
     
    Arne Vajhøj, Jun 25, 2008
    #2
    1. Advertising

  3. Mark Space Guest

    Arne Vajhøj wrote:
    > wrote:
    >> 1. Why do all the statements in constructor execute prior to
    >> statement “ new Thread(this).start();” , even if “new
    >> Thread(this).start();” precedes the other statements? For example:
    >>
    >> class A {
    >> int i = 100;
    >> A(){
    >> new Thread( this ).start();
    >> i++; // i will have value of 101 before new
    >> thread is
    >> started, even though i++ follows the
    >> statement that creates a new thread
    >> }

    >
    > I believe instance members are instantiated before constructor
    > statements.
    >
    > And you should not use this in the constructor !
    >
    >> 2. While a thread is inside a synchronized method, all other threads
    >> that try to call any synchronized methods on the same instance have to
    >> wait.
    >>
    >> So if for example process has 3 threads ( A, B and C) and A calls some
    >> synchronized method on object D, and while A is still inside D, B and
    >> C also call method on same object. While A is still inside D, will
    >> context switching still happen, even if B and C won’t do anything due
    >> to waiting on thread A to exit the monitor?

    >
    > I think that is implementation specific.
    >
    >> 3.After experimenting with a code a bit, I came to conclusion that
    >> when a thread enters a synchronized block, all other threads trying to
    >> enter synchronized block on same instance will have to wait until this
    >> thread exits the synchronized block. So, if we again have threads A,
    >> B and C and if thread A enters object’s monitor via synchronized
    >> block:
    >>
    >> synchronized( object ) {
    >>
    >> for( int i = 0; I < 1000000; i++ );
    >> }
    >>
    >> then A will get ahold of object’s monitor even if no methods are
    >> called on that object inside the synchronized block. And B and C won’t
    >> be able to enter synchronized block until A exits the synchronized
    >> block? Right?

    >
    > Yes.
    >
    >> 4. If we again have threads A, B and C and if thread A enters
    >> object’s monitor and then calls notify(), then a thread that called
    >> wait() on the same object is awakened:
    >>
    >> • but what if B and C are trying to get ahold of object’s
    >> monitor, but didn’t call wait()? Will they still get notified
    >> via
    >> notify()?

    >
    > No. What should notification mean ?
    >
    >> • if thread A calls wait(); but if then none of the threads that
    >> afterwards enter same object’s monitor ever call notify(),
    >> will A ever get awaken or will it always remain in a wait
    >> state?

    >
    > It will remain unless you the one the version with timeout.
    >
    > I think - I have never tried it.
    >
    > Arne
     
    Mark Space, Jun 25, 2008
    #3
  4. Mark Space Guest

    Arne Vajhøj wrote:
    > wrote:
    >> 1. Why do all the statements in constructor execute prior to
    >> statement “ new Thread(this).start();” , even if “new
    >> Thread(this).start();” precedes the other statements? For example:
    >>
    >> class A {
    >> int i = 100;
    >> A(){
    >> new Thread( this ).start();
    >> i++; // i will have value of 101 before new
    >> thread is
    >> started, even though i++ follows the
    >> statement that creates a new thread
    >> }

    >
    > I believe instance members are instantiated before constructor
    > statements.


    I'm not following how this bears on the OP's question. For the OP: I
    don't think "i" will always have the value 101 before the new thread is
    started. You have a race condition here. "i" might have the value 100,
    101, or it could even be in the middle of changing fro 100 to 101.

    >
    > And you should not use this in the constructor !


    True! Do you see what he means Sruby? You've give an object ("Thread"
    here) a pointer to your object A, but you aren't even done making the
    object yet. It's incomplete. In your simple example this wont matter,
    but many times it will (and sometimes in surprising ways when you get
    into synchronizing object creation between threads). Never never
    publish a this pointer from a constructor.


    >> C also call method on same object. While A is still inside D, will
    >> context switching still happen, even if B and C won’t do anything due


    >
    > I think that is implementation specific.


    What Arne means here is "it depends." D might be able to context
    switch, or it might not. You have to assume whatever is the worst for
    your application and code for that problem.

    I think the rest of Arne answers are easy to understand but I'm still
    kinda confused by the first one.
     
    Mark Space, Jun 25, 2008
    #4
  5. Arne Vajhøj Guest

    Mark Space wrote:
    > Arne Vajhøj wrote:
    >> wrote:
    >>> 1. Why do all the statements in constructor execute prior to
    >>> statement “ new Thread(this).start();” , even if “new
    >>> Thread(this).start();” precedes the other statements? For example:
    >>>
    >>> class A {
    >>> int i = 100;
    >>> A(){
    >>> new Thread( this ).start();
    >>> i++; // i will have value of 101 before new
    >>> thread is
    >>> started, even though i++ follows the
    >>> statement that creates a new thread
    >>> }

    >>
    >> I believe instance members are instantiated before constructor
    >> statements.

    >
    > I'm not following how this bears on the OP's question. For the OP: I
    > don't think "i" will always have the value 101 before the new thread is
    > started. You have a race condition here. "i" might have the value 100,
    > 101, or it could even be in the middle of changing fro 100 to 101.


    No. I believe that the Java standard specify that instance members
    instantiation (int i = 100;) happen before constructor statements
    (i++;).

    http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.5

    (point 4 and 5)

    > I think the rest of Arne answers are easy to understand but I'm still
    > kinda confused by the first one.


    Maybe I am just babbling ...

    Arne
     
    Arne Vajhøj, Jun 25, 2008
    #5
  6. wrote:
    > hiya
    >
    > 1. Why do all the statements in constructor execute prior to
    > statement “ new Thread(this).start();” , even if “new
    > Thread(this).start();” precedes the other statements? For example:
    >
    > class A {
    > int i = 100;
    > A(){
    > new Thread( this ).start();
    > i++; // i will have value of 101 before new
    > thread is
    > started, even though i++ follows the
    > statement that creates a new thread
    > }

    ....

    I don't think you have any way to evaluate when the start() method
    executes. More likely, you are looking at when the new thread executes
    its run method.

    That can happen at any time after the call to start. However, on a
    single processor system it will usually be after the next few statements
    in the currently running thread. There is a significant cost to
    switching threads, so operating systems tend to let the current thread
    go on running until it needs to wait for something or exhausts a time
    slice. You might get different results on a multiprocessor, or under
    high load conditions.

    The issue is complicated by the question of memory visibility.
    Especially on multiprocessors, threads may not see the results of
    assignments in other threads instantly.

    Given all those issues, I am reasonably sure the new thread will see i
    as having one of three values: 0, 100, and 101, but I don't think it is
    possible to predict which.

    Patricia
     
    Patricia Shanahan, Jun 25, 2008
    #6
  7. Mark Space Guest

    Peter Duniho wrote:

    > Of course, the answer is that it _does_ execute before the increment
    > statement, but he simply misunderstands what the call to Thread.start()
    > does. In particular (as you and Mark know, but apparently the OP does


    Hmmm... thinking out loud here... OTOH both the compiler and the JVM are
    allowed to re-order statements if the result is the same. Could that
    also been happening here?

    (Emphasis on the word *also*... the OP clearly has a race condition, but
    it could be made worse by the way the compiler writes the byte codes.

    In fact, there shouldn't be any access at all of a partially constructed
    object's fields, so the "i", even though public to the package, should
    not be accessed while the object is constructing. Therefore, the
    compiler could optimize it with a single write of 101 and ignore the
    "i++" statement. Of course, it also might not, so the potential for a
    race condition remains.)
     
    Mark Space, Jun 25, 2008
    #7
  8. Neil Coffey Guest

    Patricia Shanahan wrote:

    > Given all those issues, I am reasonably sure the new thread will see i
    > as having one of three values: 0, 100, and 101, but I don't think it is
    > possible to predict which.


    And of course, you shouldn't *care* which it sees with the current
    code. If you want another thread to see the variable, then you have
    to manipulate it in a thread-safe manner.

    Neil
     
    Neil Coffey, Jun 25, 2008
    #8
  9. Mark Space wrote:
    > Peter Duniho wrote:
    >
    >> Of course, the answer is that it _does_ execute before the increment
    >> statement, but he simply misunderstands what the call to
    >> Thread.start() does. In particular (as you and Mark know, but
    >> apparently the OP does

    >
    > Hmmm... thinking out loud here... OTOH both the compiler and the JVM are
    > allowed to re-order statements if the result is the same. Could that
    > also been happening here?


    I've not been reading this thread in detail, and nor am I an expert on
    the thread model of the JLS (by far the densest part, IMHO), but from
    what I understand, this is what happens:

    Let us define several events.
    Event A: i is set to default value (0).
    Event B: i is set to 100 by (implicit) constructor
    Event C: New thread is created
    Event D: i is read from in constructor
    Event E: i is written to in constructor as value+1
    Event F: i is hypothetically read from in new thread.

    Thread 1 is the thread invoking the constructor, Thread 2 is the created
    thread.

    On thread 1, clearly, the happens-before order is:
    A -> B -> C -> D -> E
    On thread 2, clearly, the happens-before order is:
    C -> F

    Applying synchronization actions, we find that C is synchronized-with F,
    so the two graphs can be merged on C.

    Therefore, we can conclude that E and F have no ordering and constitute
    a data race, while no other combination of reads or writes constitute a
    data race.

    So, assuming thread 2 doesn't write to i, event F can only see the
    values of 100 or 101 for i.

    Also in short, we can assume that the permissible reorderings do not
    include the inversion of |i++;| and the thread creation.

    Final note on this point: I have not studied this sufficiently enough to
    be fully authoritative on this topic. You may have different
    interpretations of JLS 3 §§17.4.1-4.

    > (Emphasis on the word *also*... the OP clearly has a race condition, but
    > it could be made worse by the way the compiler writes the byte codes.


    Not the bytecode (which is highly specified), but the JIT assembly.

    > In fact, there shouldn't be any access at all of a partially constructed
    > object's fields, so the "i", even though public to the package, should
    > not be accessed while the object is constructing. Therefore, the
    > compiler could optimize it with a single write of 101 and ignore the
    > "i++" statement. Of course, it also might not, so the potential for a
    > race condition remains.)


    The best way to sum it all up is, as said before, "don't let |this|
    escape a constructor..." including, especially, virtual functions.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Jun 25, 2008
    #9
  10. Joshua Cranmer wrote:
    > Mark Space wrote:
    >
    >> Peter Duniho wrote:
    >>
    >>> Of course, the answer is that it _does_ execute before the increment
    >>> statement, but he simply misunderstands what the call to
    >>> Thread.start() does. In particular (as you and Mark know, but
    >>> apparently the OP does

    >>
    >>
    >> Hmmm... thinking out loud here... OTOH both the compiler and the JVM
    >> are allowed to re-order statements if the result is the same. Could
    >> that also been happening here?


    Even if the compiler and JVM keep everything in order, there can still
    be memory order issues, especially on a multiprocessor. Maintaining full
    sequential consistency between caches can be *very* expensive and
    inefficient. Only depend on what the JLS promises.

    > I've not been reading this thread in detail, and nor am I an expert on
    > the thread model of the JLS (by far the densest part, IMHO), but from
    > what I understand, this is what happens:
    >
    > Let us define several events.
    > Event A: i is set to default value (0).
    > Event B: i is set to 100 by (implicit) constructor
    > Event C: New thread is created
    > Event D: i is read from in constructor
    > Event E: i is written to in constructor as value+1
    > Event F: i is hypothetically read from in new thread.
    >
    > Thread 1 is the thread invoking the constructor, Thread 2 is the created
    > thread.
    >
    > On thread 1, clearly, the happens-before order is:
    > A -> B -> C -> D -> E
    > On thread 2, clearly, the happens-before order is:
    > C -> F
    >
    > Applying synchronization actions, we find that C is synchronized-with F,
    > so the two graphs can be merged on C.


    I agree with this reasoning, and withdraw the claim that 0 is a possible
    value for i, reducing the set of possible values to {100,101}.

    Patricia
     
    Patricia Shanahan, Jun 25, 2008
    #10
  11. Guest

    >Of course, the answer is that it _does_ execute before the
    >increment statement, but he simply misunderstands what the call to
    >Thread.start()does. In particular (as you and Mark know, but
    >apparently the OP does not), calling Thread.start() simply makes >the newly-created Thread instance runnable. He just isn't
    >comprehending what Thread.start() actually does.


    Uh, you’re talking about me as if I was Forrest Gump. On the other
    hand, the answer is pretty obvious and I should know it… chocolate
    anyone?


    May I ask one more question - Could someone tell me why infinite for()
    loop inside synchronized block causes compile time error? Why would
    only main thread be allowed to have an infinite loop?


    Thank you all for your input
     
    , Jun 25, 2008
    #11
  12. wrote:
    > BTW – why does infinite for() loop inside synchronized block cause
    > compile time error?


    What's your actual code? The following works for me:

    class test {
    public static void main(String... args) {
    synchronized(args) {
    for (;;) {
    }
    }
    }
    }

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Jun 25, 2008
    #12
  13. Mark Space Guest

    Peter Duniho wrote:

    > There's no guarantee to the compiler that "i" isn't accessed outside the
    > constructor before the constructor completes. In fact, this particular


    Really? I'm not trying to be argumentative here, just thinking about
    how Java actually works.

    A a = new A();

    There's two things that happen here. First the call to the default
    constructor of class A, then the assignment to the variable "a".
    There's no way, even in a multi-threaded application, that "a" can be
    accessed until it's assigned a reference. Even like this:

    int i = new A().someField();

    first A has to be constructed, fully, then it's field can be accessed.
    If this code is execute by two threads, you have two objects, not two
    threads accessing one object. You have the same in the first example,
    until a is assigned a reference, and even then if a is local then you
    still have two separate objects.

    The only exception is of course publishing a reference to a reference to
    a partially constructed object, and we all know that's bad. But it's
    also not "normal" and I'm thinking that Java might optimize what is
    prescribed, and ignore what is proscribed.
     
    Mark Space, Jun 26, 2008
    #13
  14. Peter Duniho wrote:
    > On Tue, 24 Jun 2008 18:59:02 -0700, Mark Space
    > <> wrote:

    ....
    >> Therefore, the compiler could optimize it with a single write of 101
    >> and ignore the "i++" statement.

    >
    > There's no guarantee to the compiler that "i" isn't accessed outside the
    > constructor before the constructor completes. In fact, this particular
    > example is exactly the sort of thing that illustrates why that's so.
    > Since a compiler is responsible for generating logically correct code,
    > and not for making assumptions that the coder has followed some
    > desirable convention, the compiler doesn't have the ability to optimize
    > out the increment.

    ....

    "i" is not volatile and there is no action between the initialization
    and the increment that would ensure an action in the new thread
    "happens-before" the increment to 101.

    Accordingly, there is no guarantee that it is possible for another
    thread to see the 100 value, and no need for the compiler to make it
    possible.

    Patricia
     
    Patricia Shanahan, Jun 26, 2008
    #14
  15. Peter Duniho wrote:
    ....
    > If the Java compiler were allowed to assume that instance members
    > wouldn't be accessed until after the object was constructed except from
    > within the constructor itself, the language would make it an error to
    > allow the object reference to be passed out of the constructor.
    > Obviously, Java doesn't do that (and thank goodness, as there are lots
    > of valid kinds of code that would be prevented if it did) and so I
    > really don't believe that the compiler is going to make the assumption
    > that the reference isn't visible outside the constructor (well, it might
    > if the constructor never passes it to some other method...but that
    > wouldn't apply here).

    ....

    There are two distinct cases to consider, intra-thread and inter-thread.

    Within a thread, every operation happens-before any operation in the
    same thread that is later in program order. If there were a call from
    the constructor to a method that accessed i in the same thread between
    initialization and increment, the method *must* see i==100, not i==101.

    On the other hand, the specific issue is code in a different thread. The
    sample code had no calls other than the thread start call, which does
    not access any local variables in the same thread. The JLS has very
    specific rules about what ordering is required between threads. I don't
    see any of those rules as requiring any other thread to ever see i==100.

    Patricia
     
    Patricia Shanahan, Jun 26, 2008
    #15
  16. Lew Guest

    "Peter Duniho" wrote:
    > "All this focus" is because I was responding to a very specific point: the  
    > suggestion that the compiler might optimize out the initialization of 100..


    Oh, no wonder I didn't understand. It was so patently obvious that
    the compiler could not do that, since it's a run-time issue, that that
    was the source of my confusion. I just couldn't see what there was
    controversial in your claim.

    > I appreciate that you finally concluded (well, guessed, anyway) that I was  
    > correct.  But none of the rest of what you wrote was being debated.  We  
    > all agree on those points (and now on mine as well, as near as I can tell  
    > :) ).


    I completely did not understand what the fuss was about, since it's so
    blindingly obvious that the compiler could not "optimize" away the
    initialization to 100. If none of the "rest of what wrote was
    being debated", then it would have been obvious to everyone, since
    what I wrote was precisely why the compiler cannot suppress the value
    of 100.

    --
    Lew
     
    Lew, Jun 26, 2008
    #16
  17. Lew <> writes:

    > The OP wrote (// comments added and class name enhanced, SSCCEified):
    >
    >> class WrongThreader

    > implements Runnable
    >> {
    >> int i = 100;
    >> WrongThreader()
    >> {
    >> new Thread( this ).start(); // antipattern
    >> i++; // n.b., post-increment is not atomic
    >> }

    > public void run()
    > {
    > System.out.println( "i = ", i );
    > }
    > public static void main( String [] args )
    > {
    > new WrongThreader();
    > }
    >> }

    > The compiler cannot guarantee that the second thread will see 100 or
    > 101.


    Or 0.

    /L :)
    --
    Lasse Reichstein Nielsen
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Jun 27, 2008
    #17
  18. Lasse Reichstein Nielsen wrote:
    > Lew <> writes:
    >
    >> The OP wrote (// comments added and class name enhanced, SSCCEified):
    >>
    >>> class WrongThreader

    >> implements Runnable
    >>> {
    >>> int i = 100;
    >>> WrongThreader()
    >>> {
    >>> new Thread( this ).start(); // antipattern
    >>> i++; // n.b., post-increment is not atomic
    >>> }

    >> public void run()
    >> {
    >> System.out.println( "i = ", i );
    >> }
    >> public static void main( String [] args )
    >> {
    >> new WrongThreader();
    >> }
    >>> }

    >> The compiler cannot guarantee that the second thread will see 100 or
    >> 101.

    >
    > Or 0.
    >
    > /L :)


    How could it see 0? See news:HDh8k.12824$

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Jun 27, 2008
    #18
  19. Lew wrote:
    > "Peter Duniho" wrote:
    >> "All this focus" is because I was responding to a very specific point: the
    >> suggestion that the compiler might optimize out the initialization of 100.

    >
    > Oh, no wonder I didn't understand. It was so patently obvious that
    > the compiler could not do that, since it's a run-time issue, that that
    > was the source of my confusion. I just couldn't see what there was
    > controversial in your claim.


    I'm afraid that sub-thread was my fault. Despite it's patent
    obviousness, I didn't get the point until Peter explained it, because I
    was too focused on Thread's start() method as starting a new thread,
    rather than on it as a method that *might* call something that accesses
    i in the current thread.

    Apologies for denseness.

    Patricia
     
    Patricia Shanahan, Jun 27, 2008
    #19
  20. Joshua Cranmer <> writes:

    > Lasse Reichstein Nielsen wrote:
    >> Lew <> writes:
    >>
    >>> The OP wrote (// comments added and class name enhanced, SSCCEified):
    >>>
    >>>> class WrongThreader
    >>> implements Runnable
    >>>> {
    >>>> int i = 100;
    >>>> WrongThreader()
    >>>> {
    >>>> new Thread( this ).start(); // antipattern
    >>>> i++; // n.b., post-increment is not atomic
    >>>> }
    >>> public void run()
    >>> {
    >>> System.out.println( "i = ", i );
    >>> }
    >>> public static void main( String [] args )
    >>> {
    >>> new WrongThreader();
    >>> }
    >>>> }
    >>> The compiler cannot guarantee that the second thread will see 100 or
    >>> 101.

    >> Or 0.
    >> /L :)

    >
    > How could it see 0? See news:HDh8k.12824$



    The class has int field called "i". As an int field, its initial value
    is zero, and it is not set to 100 until after the superclass' constructor
    has run. That would be Object's default constructor, which doesn't do
    a lot, but it's there.
    I.e., at some point the value is zero.

    The other thread, when started, accesses the value of the field from a
    different thread than where it was assigned the values 100 and 101,
    without any synchronization. Therefore the other thread should also
    be able to see the stale value "0".

    /L
    --
    Lasse Reichstein Nielsen
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Jun 27, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Shailender Bathula
    Replies:
    1
    Views:
    773
    Sanjay
    Feb 17, 2005
  2. Dimitri Ognibene
    Replies:
    0
    Views:
    400
    Dimitri Ognibene
    Apr 25, 2006
  3. Replies:
    7
    Views:
    418
  4. Replies:
    4
    Views:
    388
    Daniel Pitts
    Feb 8, 2008
  5. Zd Yu
    Replies:
    7
    Views:
    139
    Zd Yu
    May 16, 2011
Loading...

Share This Page