Re: stale objects in collections

From:

Eric Sosman <Eric.Sosman@sun.com>

Newsgroups:

comp.lang.java.programmer

Date:

Mon, 21 Aug 2006 15:01:54 -0400

Message-ID:

<1156186915.91926@news1nwk>

Timo Nentwig wrote On 08/21/06 13:38,:

Hi!

I'm not entirely sure whether the Set needs to be synchronized. I think
yes, but would like to ask people here anyway, pseudo-code:

class Test{
  final Set set = Collections.synchronizedSet(new HashSet()):

  class MyThread extends Thread{
    void run(){
      while(foo) {
      // set is either written to read from never both
       set.put(someObject):
     }
    }
  }

  public main(){
   Thread t = new Thread[10];
   for( int i = 0; i < t.length... )
    (t[i] = new MyThread()).start();

   for( int i = 0; i < t.length... )
    t[i].join();

  // this thread may (not) see stale objects in the collection
  // without synchronization (?)
  dump(set);
}
}

    Hard to be sure of your intent, because the sample code
isn't really Java but a sort of Java-ish patois. But if
there's only supposed to be one Set shared by the whole bunch
of MyThreads, then yes: The Set needs synchronization because
multiple threads are calling its methods "simultaneously."
The synchronizedSet() wrapper provides all the synchronization
you need at the level of individual method calls, but you need
additional protection if you want to make a sequence of method
calls "atomic:"

    // WRONG
    if (set.isEmpty()) {
        //
        // "set" can change here
        //
        set.add("Elvis");
    }

    // RIGHT
    synchronized(set) {
        if (set.isEmpty()) {
            set.add("Elvis");
        }
    }

    There's no problem with staleness at the end of main()
because [1] all the competing threads have been joined and
thus can no longer interfere with the Set, and [2] the join()
call itself is a synchronization point for the purposes of
things like memory visibility.

--
Eric.Sosman@sun.com