3 Replies Latest reply on Jul 22, 2010 8:15 AM by EJP

    RMI and happens-before semantics


      I looked through the specs and did not find the information whether method invocations through RMI imply a happens-before relation, either between the client and the server threads or the other way, between server and the client threads.

      Example. We have a remote reference to a ServiceFactory (server side) which is used by client to obtain another remote reference, to the Service object, which is created and initialized on the server side. There is no explicit synchronization in the code of ServiceFactory and Service.
        ServiceFactory factory = ...
        Service service = factory.createAndInitNewService(); // RMI call: returns a remote refrence
        State state = service.getState(); // RMI call
      Can we assume that all the initialization of the service which happens on the server (factory.createAndInitNewService()) will happen before the method returns on the client side, and whether the call of getState() will happen before the read of the state on the server?

      Thanks in advance
        • 1. Re: RMI and happens-before semantics
          Of course you can. The client calls the remote method, it runs, it returns a value or void or throws an exception, and the client receives that value/void/exception. What other order could it possibly execute in?
          • 2. Re: RMI and happens-before semantics
            Of course that those calls will be physically carried in the expected order, but my question is about the impact of those calls on the memory consistency in the server.

            When server runs on SMP environment, then two consequtive calls (ceateAndInitNewService and then getState) can be handled in two separate threads. Now, if there is no "happens-before" relation between instructions in those threads, then the second thread could have a different view of the memory than the first thread, and hence returning incorrect object state.

            Typically a happens-before relation occurs between instructions in two threads when (briefly):
            - two threads synchronize on the same monitor or lock
            - upon read/write on volatile field
            - when one thread forks another
            - one thread joins another.
            - concurrent collections set a happens-before relation on some operations.

            My question is whether RMI calls can be assumed to also create such relation between client and server threads around RMI calls, so that we do not need to synchronize the server code for such simple use cases.

            For info on java memory-model see this: http://java.sun.com/docs/books/jls/third_edition/html/memory.html
            • 3. Re: RMI and happens-before semantics
              Thanks, now that I know what you're talking about it's clear. I doubt that RMI does any specific magic about this. In practice two successive calls from the same client would execute within the same server thread if within the connnection idle timeout; otherwise, that thread would have exited, which must surely be a memory barrier event itself, before the 2nd call, causing the client to form a new TCP connection & thus start a new server thread, which again is surely a memory barrier event. So I don't think it can be an issue. If you're concerned, do some synchronizing yourself.