Improvements of the Object System

General Remarks

The Oz object system was adapted to sequential composition. This adaptation uses reentrant locks to achieve mutual exclusion. Furthermore, there were some minor semantic changes. Purely syntactic changes are described in syntax.

Locks

Oz supports reentrant locks. A reentrant lock can be defined by L={NewLock}. Using such a lock as in lock L then S end prevents different threads from concurrently executing statements protected by the same lock L. If a thread encounters a locked statement of the form lock L then S end and a different thread is currently executing a locked statement with the same lock, the former thread will block until the latter thread has left all locked statements with the lock L. Note that locking does not prevent a thread from entering several statements locked with the same lock. Therefore, we call them reentrant locks.

Sequential Objects for Sequential Composition

A consequence from explicit concurrency (see sequential composition) is that the restrictive monitor semantics of objects can be dropped. In Oz, as in sequential object-oriented languages, object and method application (message sending) is nothing but a dynamically dispatched procedure call. Different threads may access and modify shared objects concurrently. We decided not to prevent this in general---as was done by the monitor semantics of objects in Oz 1---for simplicity and flexibility.

Using the idea of locking we provide a mechanism to use objects safely in a concurrent setting:

Classes can have the property locking. A class has this property if its definition includes prop locking or if it inherits from a locking class. Instances of locking classes are lockable.

In methods of lockable objects, a code segment may be enclosed by lock ... end indicating that only one thread can enter such a locked statement on a given object at a time. In other words, this syntax provides for a mechanism to implicitly introduce a lock per object which is used by every lock ... end statement.

Minor Changes

• UrObject was renamed to BaseObject.
• Batches (messages consisting of lists) are not provided by BaseObject.
• Master/slave mechanism is not supported by BaseObject. Instead there are classes Object.master and Object.slave.
• The concept of closing objects is not needed any longer. BaseObject does not provide a method close.
• Classes can have the property final, indicated by prop final in the class definition. Such classes cannot be inherited from.