Writing Threadsafe Code in RMI

1
Writing Thread-safe Codein RMI
Celsina Bignoli bignolic_at_smccd.net
2
Thread Synchronization

• Thread share the same memory space
• each thread has its own stack trace of course
• but they share the heap
• synchronization is needed to maintain
• data integrity
• control access to shared resources

3
Monitors

• a region of code representing a shared resource
  can be associated with a monitor (a.k.a.
  semaphore)
• threads access the shared resource by first
  acquiring a lock on the monitor
• only one thread can own the monitor at one time
• monitor implements a mutually exclusive locking
  mechanism (a.k.a. mutex)

4
Rules of Synchronization

• if a thread has acquired a monitor no other
  thread can enter it. they will need to wait for
  the monitor to become available
• when a thread exists a monitor a waiting thread
  can then acquire it and access the resource to
  which it is associated

5
Synchronized methods

• methods on a object that should only be executed
  by one thread at a time must be modified with the
  keyword synchronized
• a thread wishing to execute a synchronized method
  must first enter the objects monitor.
• calling the method automatically does that
• if the monitor is owned by another thread, the
  method must wait
• a thread exits a monitor when the method returns

6
Synchronized methods(2)

• methods on a object that should only be executed
  by one thread at a time must be modified with the
  keyword synchronized
• a thread wishing to execute a synchronized method
  must first enter the objects monitor.
• calling the method automatically does that
• if the monitor is owned by another thread, the
  method must wait
• a thread exits a monitor when the method returns
• when a thread owns a monitor all other threads
  cannot execute the same or any other synchronized
  method of the object
• non-synchronized methods can be called at any
  time by any thread
• the threads that owns the monitor can perform any
  other synchronized method (reentrant
  synchronization)

7
Static Synchronized Methods

• classes have a monitor associated to them
  analogous to the object monitor
• a thread wishing to execute a static synchronized
  method must first enter the class monitor.
• when a thread owns a monitor all other threads
  cannot execute the same or any other static
  synchronized methods of the class
• non-synchronized static methods can be called at
  any time by any thread
• synchronization of static methods of a class is
  independent from synchronization of methods on
  objects of that class

8
Synchronized Blocks

• allows arbitrary code to be synchronized on the
  monitor of an arbitrary object
• allows more fine-grained synchronization
• once a thread enters the code no other thread can
  perform the same synchronized block or any other
  code requiring the monitor.
• synchronized (ltobject referencegt)
• ltcode blockgt

9
Deadlocks

• public synchronized void method1()
• object2.method2()
• public synchronized void method2()
• object1.method1()

10
Threading and RMI

• RMI creates multiple threads
• if multiple clients make simultaneous method
  calls, RMI service them on multiple threads
• Server must be thread-safe

11
Ensure Data Integrity

• better be thread-safe than sorry
• synchronizing large pieces of code slows the
  system down and can lead to bottlenecks
• HOVEVER
• not putting sufficient synchronization into your
  code can lead to data corruption which might not
  be possible to recover!

12
Thread-safe Code - Solution 1

• Synchronize all methods
• Problem
• the lock is not kept between method calls
• can lead to undesired situations

13
Thread-safe Code - Solution 2

• add getLock(), releaseLock() methods to be
  called by client (see Account2 and Account2_Impl
  examples)
• Problems
• increased number of method calls
• never a good idea to send too many method calls
  through the wire for performance reasons
• vulnerability to partial failure
• if something goes wrong between getLock() and
  releaseLock() the lock is NEVER released!
• server is vulnerable to malfunction on the client

14
Thread-safe Code - Solution 3

• Automatically grant a lock
• Use background threads that expires the lock
  when client has not been active for a certain
  time (see Account3 and Account3_impl example)
• Problems
• the code is more complicated
• threads are expensive
• consume memory and system resources
• OS puts a limit on number of threads per process

15
Thread-safe Code - Solution 4

• Use a single background thread to expires all
  the lock (see Account3_Impl2 example)

16
Minimize Time Spent in Synchronized Blocks

• Synchronize around the smallest block of code
• do not synchronize across device accesses
• do not synchronize across secondary remote method
  invocations

17
Synchronize Across Device Access
Server Object
Server Object
Singleton Logger
File
Server Object
Server Object
18
Synchronize Across Device Access
Server Object
Server Object
Singleton In-memory Logger
File
Background Thread
Server Object
Server Object
19
Container Classes

• Hashtable and Vector are thread-safe
• each of the methods defined in them is
  synchronized
• Still, need to pay attention about what needs to
  be done with these classes!
• public void insertIfAbsent(Vector v, Object o)
• if (v.contains(o))
• return
• v.add(o)

20
Container Classes (2)

• public synchronized void insertIfAbsent
• (Vector v, Object o)
• if (v.contains(o))
• return
• v.add(o)
• public void insertIfAbsent(Vector v, Object o)
• synchronized(v)
• if (v.contains(o))
• return
• v.add(o)