se.lth.cs.realtime
Interface Synchronized

All Known Implementing Classes:

RTEventBuffer

public interface Synchronized

Empty interface stating that the implementing class is thread safe by means of synchronized methods, conceptually comprising a monitor [Hoare 1974]. There are five ways of implementing thread-safe objects:

1. Mutual exclusion by means of the Java built-in construct synchronized.
2. Mutual exclusion by other mechanisms such as semaphores.
3. Atomic operation by disabling interrupts or preventing preemption.
4. The method only uses local data (allocated on the stack of each thread) or external data that comprises constants (such as Pi in Math) or monitors (such as the mailbox monitor inside JThread.putEvent.
5. Attributes are public (or package visible) but declared and the logic of the code is written such that object interaction is thread safe.

Items 1 and 4 represent the normally acceptable alternatives. Classes that provide methods that are all thread safe according to these alternatives could/should implement Synchronized, thereby permitting additional checking of the code (by special tools).

Standard programming: Implement this (empty) interface and declare all methods synchronized.

Advanced programming: In Java where the mutual exclusion of monitors are accomplished by the use of the keyword synchronized, whereas monitors as defined by Hoare are not explicitly supported in the language or in the standard libraries (but the name of the byte-codes refer to monitors). Due to the lack of language support, external tools or test suits have to check that a class that implements Synchronized really comprises a monitor, with some refinements due to object orientation. Specifically, this means that the class implementing this interface should:

• Have all non-private methods synchronized.
• Have no public or package-visible fields.
• Any protected (which implies package visibility) field may not be referenced from within the same package.
• Methods that are synchronized, without being declared synchronized according to the first item, should use an internal non-public object as an attribute for locking. That is, with a private lock an unsynchronized method can contain synchonized(lock){...}, which prevents wait/notify-interference from outside the monitor. A method that is synchronized this way may not access monitor fields outside the scope of synchronized, but local data and calls of other thread-safe methods are permitted. For axample, the following is also acceptable since arrival will be allocated on the stack of each calling thread and currentTimeMillis() is thread safe.

        public void monitorMethod() {
            long arrival = RTSystem.currentTimeMillis(); // This line is OK!!
            synchronized (lock) {
                // Using monitor attributes here....
            }
        }

• Any static non-final attributes may only be referenced by static synchronized methods, or by synchronizing (inside the non-static monitor object method) on the class object for the entire scope of the non-static method.
• 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 crititcla section.

Since synchronized is not inherited, is is very important that subclasses of classes implementing Monitor also obey the items above, remembering to implement each (virtual synchronized) method according to the monitor rules above.