This content has been marked as final. Show 3 replies
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?
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
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.