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
||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.|
||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.
||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.
||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.|
||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.
||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)
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.
||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.
||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.|