se.lth.cs.realtime
Interface Synchronized

All Known Subinterfaces:

Monitor

All Known Implementing Classes:

RTEventBuffer, Synchronized.Lock

public interface Synchronized

Empty interface stating that the implementing class is thread safe, typically by means of synchronized methods. An object instance could then (by use of special tools) be checked that it conceptually comprises a monitor [Hoare 1974], with some differences that can be further avoided by using the Monitor interface.

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 simple programming: Implement this (empty) interface, declare all methods synchronized, have attributes protected or private, and beware (for method implementations) that threads using other objects may run code that calls (and interferes with) wait and notify on this object.

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 synchronized(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 example, 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.

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

See Also:

License

Nested Class Summary

static class

Synchronized.Lock