A JavaSpace may be just what you need.  Check out
http://www.jini.org, and
http://www.jini.org/wiki/Links#Jini_Implementations in particular.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                      | systems design and implementation.
         pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)

The meta-suggestion is to read a tutorial or book on synchronization.
However, here is a pattern for your situation:

Thread A:

synchronized(x){
  set a shared variable to indicate A has completed
  x.notify();
}

Thread B:

synchronized(x){
  while(shared variable indicates A has not completed){
    x.wait();
  }
}

x must refer to a single object.

If B arrives at the synchronized block after A has finished, then the
shared variable will tell it to go ahead without waiting. If B arrives
at the synchronized block before A has finished, then it will go into
the wait, but A will subsequently issue a notify.

Of course, this is only an outline. In real code, you will need to deal
e.g. with interrupts.

Patricia

If B requires the result of A, you might look into Future<T> and Executors.
The Java concurrency packages have very useful tools for exactly the
thing you want to do.
Here's a short example:
<SSCCE>
import java.util.concurrent.*;
class ResultA {}
class ResultB {}
class TaskA implements Callable<ResultA> {
   public ResultA call() {return new ResultA();}
}

class TaskB implements Callable<ResultB> {
   Future<ResultA> futureResult;
   public TaskB(Future<ResultA> futureResult) {
      this.futureResult = futureResult;
   }
   public ResultB call() throws Exception {
     doSomeStuff();
     ResultA resultA = futureResult.get();
     doSomeStuffWith(resultA);
     return createResultB();
   }

    private ResultB createResultB() {return new ResultB();}
    private void doSomeStuff() {}
    private void doSomeStuffWith(ResultA resultA) {}
}

public class Main {
   public static void main(String...args) throws Exception {
       ExecutorService executor = Executors.newCachedThreadPool();
       Future<ResultA> futureA = executor.submit(new TaskA());
       Future<ResultB> futureB = executor.submit(new TaskB(futureA));
       futureB.get();
   }
}
</SSCCE>

You should probably read more about concurrency in Java. There are some
good tutorials. There is also an excellent book called Java Concurrency
In Practice
<http://virtualinfinity.net/wordpress/technical-book-recommendations/java-concurr
ency-in-practice/>

I suggest reading at *least* one of the above.

Hope this helps, and good luck.

Split B into two parts B1 and B2. B1 being the part independent of A.
B2 being the part that requires the input from A (and now from B1,
too). Initialize a CountDownLatch with a count of two. Provide an area
(object) where A and B1 can store their results and B2 can fetch them
from. Start A, B1 and B2 in parallel. Let B2 immediately block on the
CountDownLatch by calling await(). Let A store its result and
countDown() the CountDownLatch when A is done. Let B1 do the same.

Alternatively, do it asymmetric. Initialize a CountDownLatch to one.
Let only A count it down when A is done. Place the await() call at the
end of the B1 code. Place the B2 code directly after the await() call.
Only start A and B1 in parallel. If A is faster than B1 await() will
return immediately and continue executing the B2 code. If A is slower
than B1 the await() call will block until A is done.

Tom Forsmo wrote On 11/20/07 16:33,:

   You misunderstand wait() and notify() -- don't be ashamed,
because you are not the first to do so and will not be the
last.  The only thing notify() does is to awaken a thread
from a wait() on the designated object, *if* a thread happens
to be sleeping in a wait() at that moment.  If no thread is
sleeping, notify() is a no-op; it does not create a "notified"
state somewhere.

   What B really needs is not a notification, but A's result.
So let's do it this way:

    class B {
       Result fromA = null;
       Object sharedLock = new Object();

       void doIt() {
           doPreliminaryThings();
           synchronized(sharedLock) { // acquire lock
               while (fromA == null) {// any result yet?
                   sharedLock.wait(); // no: unlock, sleep
                                      // ... and re-lock
               }
           }                          // yes: unlock
           doLaterThings(fromA);      // use the result
       }
    }

    class A {
       B theB = ...;

       void doIt() {
           Result result = inventSomething();
           synchronized(theB.sharedLock) { // acquire lock
               theB.fromA = result;        // store result
               theB.sharedLock.notify();   // sleeper, awake!
           }                               // unlock
           // done!
       }
    }

   Notes:

   1) With this pattern it doesn't matter whether A or B
is faster.  If A is faster, it stores its result in fromA
and performs a no-op notify(); B will later find fromA non-
null and will not wait at all.  If B is faster, it finds
fromA null and waits for the situation to change; A eventually
stores to fromA, and in this case its notify() actually wakes B.
Even a dead heat is fine: since one and only one of A and B
can run its synchronized block while the other stalls, that
one effectively "gets there first" and breaks the tie.

   2) A "holder" object like a Collection or an array or
something of your own devising can fill the roles of fromA
and of sharedLock simultaneously.  (Can you see why the
reference variable fromA all by itself won't do the whole
job?)

   3) Observe that B uses `while' and not `if'.  A return
from the wait() method doesn't mean that A *has* called
notify(), only that it *may have* called notify(), so B
must go around and check again -- and possibly go back to
sleep again.  Besides, remember the first principle: B is
not interested in the notification, but in the result, so
it's the presence of the result that's the sure-fire test
for whether to proceed.