Last week's column defined the rule of ownership. Every object has exactly one owner, the object responsible for its creation and destruction. The responsibility of ownership cannot be transferred to another object.

By objects, I'm talking not only in the object-oriented sense. All entities in a software system, from database records to program variables to COM objects, must obey the rule of ownership. These types of objects use referential integrity, scope, and reference counting, respectively, to implement ownership, but the rule is always the same.

While ownership can be properly implemented in Java, it takes discipline; garbage collection does not confer ownership for free.

RDBMS using referential integrity

Take, for example, ownership among records in a relational database. Ownership defines a strict one-to-many master-detail relationship between tables. No detail record should exist without a master record. To enforce this, we use the facilities of the DBMS to enforce referential integrity. Deletion cascades from master to detail. If you fail to properly define these relationships, you will end up with orphaned records, or worse, lost data.

C++ using scope

In C++ scope helps us define ownership. Define a member variable of class type within another class, and the inner object cannot outlive the outer. The owner intrinsically creates and destroys the owned object. Furthermore, ownership cannot be transferred. The owned object can be copied, certainly, but the copy has unique identity; the copy and the original can be changed independently. Using scope in this way, it is difficult to violate ownership.

However, the static relationship that scope implies is often not sufficient, at which time it is necessary to use pointers. When using pointers, you must manually implement ownership to avoid memory leaks, protection faults, and other nasty bugs. This requires careful use of the new and delete operators, and of constructors and destructors.

Java using scope with garbage collection

Java combines scope with garbage collection to avoid some of the memory bugs to which C++ pointers are prone. Java uses mark-and-sweep to destroy objects. At arbitrary intervals, program processing suspends and the garbage collection algorithm executes. First all objects are marked, then the network of objects starting from the root is swept clean. All objects left marked have no reference path from the root, and are therefore destroyed. At this point, program processing resumes.

This mechanism, however, is not without its problems. Mark-and-sweep is a time-consuming algorithm that is executed at intervals that seem arbitrary to the application. This is the root of many of Java's performance problems. Furthermore, all references to an object share in its ownership, violating the core of the rule. While ownership can be properly implemented in Java, it takes discipline; garbage collection does not give you ownership for free.

COM using reference counting

COM objects use reference counting to control the life cycle of an object. Every COM object must implement the core interface IUnknown and keep an internal reference count. Two methods of this interface, AddRef and Release, increment and decrement the reference count, respectively. When the reference count returns to zero, the object should destroy itself.

While reference counting does not impose the performance problems of mark-and-sweep, it does have its own set of caveats.

First, all clients of COM objects must be sure to properly call AddRef and Release. With smart pointers in C++ or built-in COM support in Delphi and Visual Basic, this is becoming less of a problem -- but it still exists. Second, when objects are connected with circular references, care must be taken to avoid creating an object island. Even though no external object references them, the objects within the island reference one another, thereby keeping all reference counts above zero. Third, objects may depend upon relationships with other objects to define their behavior. In such cases, a reference to any object should keep the entire network intact. The developer must create a special implementation of AddRef and Release to accommodate this requirement.

Ownership is a discipline

The above analysis shows that different technologies offer different facilities for implementing ownership. No matter what language, tool, or library you use, you must understand these facilities and their ramifications. The proper implementation of ownership is always a discipline: You can never fully rely on any technology to implement it on your behalf.

In next week's installment, we will look at some of the consequences of ownership violations. You will also have a chance to test your knowledge of ownership with a particularly challenging spot-the-bug problem.

» posted by abennett

ITworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine