Improvements of the Object System

  • Main Home Page

  • Features

  • Sequential Composition and Explicit Thread Creation

  • Objects

  • Exception Handling

  • Syntax Improvements

  • Standard Modules

  • Window Programming

  • Finite Domain Constraints

  • Record Constraints

  • Efficiency

  • Tools

  • Documentation

  • Download


  • 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


    Martin Henz