se.lth.cs.realtime
Interface Monitor
- All Superinterfaces:
- Synchronized
- public interface Monitor
- extends Synchronized
Support for the concept of monitors ([Hoare 1974]) by imposing further rules, such
as limitations on external syncronization. An object implementing
a Monitor must be thread safe as expressed by the
base-interface Synchronized, but also the following applies for code
that uses/inherits/implements a Monitor object:
- Using only the keyword
synchronized, or even implementing the
interface Synchronized, it can be the case that other objects
calls wait and notify on an object that needs to be thread safe. That imposes
restriction on method implementations, typically making the less readable or
less efficient (taking care of excessive unknown notifications, and the like).
By implementing this interface, you state that such external synchronization is
forbidden.
- Methods that are non-blocking (not calling
wait) in a non-abstract
base class may not contain calls to wait in a subclass. During wait
the object is temporarily unlocked, which other monitor methods (as defined in
the base class) are designed to handle. By not permitting subclass methods to
introduce waiting, some cases of deadlock is avoided and (more important)
concurrency faults due to unexpected unlocking when base class methods call
virtual (non-final) methods that unexpectedly breaks the critical section.
- Special support for multiple conditions is enabled, that is, having multiple
Condition objects for calling wait/notify on more specific monitor
conditions This is made possible by the first item above. For compiled Java this
depends on the compiler. For JVM execution the application/applet should
be started via Main.main, for best efficiency.
These items all contribute to making a Monitor object being more
conform with definitions in the literature, but also better corresponding to
typical implementations in available RTOS:s, thereby facilitating compilation to
efficient executables for such platforms.
- See Also:
License