Publish and Subscribe
Publish & Subscribe
Publish & Subscribe (P&S), is an IPC mechanism also known as ‘properties’ that provides a means to define and publish system-wide ‘global variables’. Such properties are communicated to more than one interested peer asynchronously.
This Publish & Subscribe API can be used by both user- and kernel-side programs, via similar APIs, and thus can also provide asynchronous communication between user- and kernel-side code. In the following only the user-side usage is discussed.
Threads with P&S may have the role either of the publisher or of the subscriber, while anyone can be the one which defines the property to be published. Such properties are single data values, uniquely identified with an integral key. Properties have identity and type. The identity and type of a property is the only information that must be shared between a Publisher and a Subscriber – there is no need to provide interface classes or functions, though that may often be desirable in many designs.
There are six basic operations that can be performed on properties:
- Define: Create a property variable and define its type and identity
- Delete: Remove a property from the system
- Publish: Change the value of a property
- Retrieve: Get the current value of a property
- Subscribe: Register for notification of changes to a property
- Unsubscribe: Deregister for notifications of changes
Of these operations, the first two need to be coupled in the same thread, as it is only permissible for the defining thread to delete a property. Once defined, the property persists in the kernel until Symbian OS reboots or the property is deleted. Subsequently its lifetime is not tied to that of the thread or process that defined it. When properties are deleted any outstanding subscriptions for this property will be completed to the subscribers, indicating that the properties cannot be found (anymore).
As said, either publishers or subscribers may define a property, so it is not required that a property be defined before it is accessed. This paradigm allows for lazy definition of properties, hence publishing a property that is not defined is not necessarily a programming error.
For some operations such as publication and retrieval of properties, there are two modes of transaction. Although P&S operations are as far as applicability is concerned connection-less; in fact they can be used either transiently or after having set up the association between user and property, in the kernel. Thus publishers and subscribers may ‘attach’ to properties prior to operation. Subsequently properties can be published or retrieved either by using a previously attached handle, or by specifying the property category and key with the new value. In EKA2 systems, the benefit of the former is the deterministic bounded execution time, suitable for high-priority, real-time tasks; with the exception of publishing a byte-array property that requires allocating a larger space for the new one.
In addition, properties are read and written atomically, so it is not possible for threads reading the property to get an inconsistent value or multiple for simultaneous published values to be confused.
As far as subscriptions and cancellations are concerned, clients of P&S must register their interest, by attachment, prior to usage. This is due to the asynchronous nature of the notification. For the kernel to recognize deterministically which threads need to be notified of a change in some property, that interest needs to be first associated to the property. Notification of a property update happens in effectively four stages. Initially a client registers its interest in that property. Then, upon a new publication of that property’s value the client gets notified (by completion of its subscription request). Finally after notification the client initiates the retrieval of the updated property.
For further reference: