Win a copy of TensorFlow 2.0 in Action this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

Is RMI threadsafe?

Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was thinking yes until I saw this on the web :
"RMI is not threadsafe, i.e. when working with threads you still need to take care of synchronization yourself. (for more see RMI specification
3.2 Thread Usage in Remote Method Invocations)"
here is what the link refers to :
"3.2 Thread Usage in Remote Method Invocations
A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. Since remote method invocation on the same remote object may execute concurrently, a remote object implementation needs to make sure its implementation is thread-safe."
is it or no?
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I dislike the expression "X is threadsafe". It leads to piles of confusion.
An statement that comes up often in this and other forums is "it's better/easier to use a Hashtable than a HashMap, because a Hashtable is threadsafe".
Yes, Hashtable is threadsafe in the sense that its methods are synchronized so that you won't wreck the data structure when you access it using multiple threads. That does not mean that any code you write using the Hashtable is threadsafe. In fact I have argued many times here and elsewhere that it is actually more likely to be threadunsafe because the so-called thread safety of Hashtable lures you into a false sense of security. It doesn't help you. For 90% of the problems, the synchronization of a Hashtable is in entirely the wrong place, at entirely the wrong granularity, because the operations that need to be atomic with respect to other threads are much coarser grained than the little Hashtable methods.
The boys from Sun recognised this, of course, and introduced the mercifully unsynchronized Collections framework in JDK 1.2. In the rare cases that a synchronized Collection is called for, you can use the Collections.synchronizedFooBar() wrapper classes.
Back to RMI.
RMI is threadsafe in the sense that Hashtable is threadsafe: accessing RMI using multiple threads, or from multiple JVMs, won't wreck it. It fully supports this mode of operation. That does not mean however that your remote objects are threadsafe. You will have to take care of that yourself; with very few exceptions, you would do that in exactly the same way as you would ensure the thread safety of local, non-RMI objects. For the purpose of the assignment, the exceptions aren't important (they have to do with callbacks and all that jazz).
Other than Hashtable, however, RMI itself must be threadsafe as well in order for it to be useful, so don't take this as a plea for an unsynchronized RMI implementation
Does that clarify things?
- Peter
[ January 06, 2003: Message edited by: Peter den Haan ]
Daniela Ch
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It means our mission is in jeapordy! Quick, read this tiny ad!
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic