Patterns & Names

Design patterns enable us to communicate more effectively with our peers by assigning names to programming idioms. Each software developer evolves his bag-of-tricks over the years, as new and better solutions to programming problems are discovered. This page attempts to document the names of the patterns found in the OSCL, and give some insight into their meaning.

Name	Pattern Description
Creator	A Creator is an entity which is responsible for the life-cycle of another entity. It is typically a (static) Service that is responsible for the creation and destruction of another (dynamic) Service. An example might be a Service that uses a lower level Service to discover that a USB device has been inserted onto a USB bus. The Creator might subsequently discover the type of the new device and register a new device driver Service for that particular type of device.
Server	A server in this context is the combination of a thread, and a set of one or more services that execute on that thread. A server typically has an ITC mailbox that is shared by all of "its" services.
Service	A service is a complete software subsystem that executes on a thread and may send and receive ITC messages. Services are generally quite asynchronous and event driven in their operation. Most services support Open/Close ITC messages that act as a kind of "constructor/destructor" in the concurrency domain.
Part	A service is sometimes composed of one or more "Part"s that encapsulate a major interface of a "Service." Some Parts are designed around abstract interfaces to allow for alternate implementations. Other parts are quite specific to a particular implementation Context, and are therfore tightly coupled to the overall Service or other Parts. Most parts support start/stop operations that act to support the dynamic instantiation and destruction of the Part. The stop operation is typically asynchronous and a call-back is used to signal the Context when the Part is stopped. It is also common for the Context to supply the memory used by the Part for stopping its operation. This reduces the amount of memory required as the Context can then sequence the stopping of its consituent Parts reusing the same memory.
Transaction	Transactioins are similar in many ways to Parts. Each transaction encapsulates the behavior and resources necessary to asynchronously accomplish some task. The Context may then have one or more of these Transactions executing simultaneously, and the actual number may be varied depending upon the needs of the application and the amount of memory dedicated.
Config	A Config is a template that declares a particular object and allocates memory and other resources for a particular Service or Part. The purpose is to separate the configured class from its resource limitations, allowing the resource limitations to be specified on a case-by-case (use-by-use) basis. Even if the Config is not used, it provides a concrete example of how the resource needs of the configured class may be allocated to to instantiate the configured Service or Part. Aside from construction, Configs generally have very little if any behavior.
Blocker	A Blocker is a Server that has exactly one Service. That Service is normally blocked waiting for a semaphore. While in this condition, such Services cannot receive ITC messages. This pattern requires that each instance have its own thread.
Driver (Hybrid)	A Driver is a type of Service that has a Mailbox upon which it waits for ITC messages (like a standard Service). The Mailbox has the ability to return from the wait operation with a NULL message pointer that indicates the "Mailbox Semaphore" has been signalled. Driver Services are very useful for the implementation of interrupt driven device drivers. The interrupt service routine for the device signals the "Mailbox Semaphore", and the Service runs (returns from waiting on the Mailbox with a NULL message) and services the device. Like standard Services, Driver typically implement Open/Close ITC messages, and can thus be run-time dynamic.
Advertiser (ADV)	An Advertiser is an active object whose purpose is to maintain a list of Dynamic Objects. The Advertiser provides an ITC interface to its clients that allow them to detect changes in the list and subsequently atomically iterate the list. An Advertiser is only capable of advertising Dynamic Objects of one particular type according to its template parameter.
Dynamic Object (Dynamic Service)	A Dynamic Object is an active object whose life-cycle is dynamic. Dynamic Objects are instantiated by a Creator based on the criteria of the Creator. Clients are required to hold a reference counted handle to the Dynamic Objects that they use. Clients which have handles for an indefinite period of time are required to register with the corresponding Dynamic Object for release notification. Upon receiving a release notification response, a client is required to cease using the Dynamic Object and then to release its reference counted handle.
Onion	An Onion is a term used for a very large grained object which typically contains many sub-objects that all have the same life-cycle. The term Onion comes from the fact that such an object may contain many layers of a system within a single object. Onions are almost always Dynamic Objects.