Inter-Thread Communication in Symbian

So far I wanted to have e methodological approach, a bottom-up one, from Symbian’s atoms to the general picture, going through the boot process on a Symbian enabled smartphone.

Symbian OS provides several such mechanisms, including shared I/O buffers, publish and subscribe, message queues and client-server.

Client-server is the original Symbian OS inter-thread communication (ITC) mechanism, having been present from the earliest implementations of EPOC32 in the Psion Series 5 right up to the latest mobile phones deployed on the secure platform of Symbian OS v9.

The managing of central resources using the client-server paradigm can be seen throughout Symbian OS, with all the major services provided by Symbian OS being implemented using this method. The file server (F32), the window server (WSERV), the telephony server (ETEL), the comms server (C32) and the socket server (ESOCK) are all examples of central resources managed by a server and accessed by a client interface to them.

So … what to say about the original and ubiquitous Client/Server Inter-Thread communication mechanism ?

Clients connect to servers by name and first establish a session that then provides the context for all further communication between clients and server. Such session-based communication comprises of client requests and server responses (a handshaking mechanism that needs to exist before exchanging data). Due to its connection-oriented session-based communication, client/server is a guaranteed request completion mechanism.

For communication to take place, a session has to first be established in the kernel, with a guaranteed number of message slots for the server. This connection in EKA1 is always synchronous as is the disconnection from the server. Session-based communication ensures that all clients will be notified in the case of an error or shutdown of a server, as well as that all resources will be cleared when something goes wrong or when a client disconnects or dies.

In case you were not already familiar with Client/Server paradigm maybe the picture below will be useful

This is very useful when the user initiates the communication, the clients will have to initiate a connection to the server and the server is there to respond on demand … but as we have moved through to always-connected communicating devices, many interactions are not anymore user controllable. This ITC mechanism carries some limitations :

  • clients have to be aware which server will handle their request
  • a permanent connection has to be maintained during the communication, clients are locked to a specific server until the communication is shut-down
  • servers’ response is guaranteed but not also its time, cannot have a limited time of the execution, making it unsuitable for real-time applications
  • higher risk of deadlocks due to its synchronicity nature

In order to overcome those issues new ITC mechanisms were introduced in later Symbian OS releases, mainly with v8.0. Those are …

Publish and subscribe … another means of thread communication. (quite later introduced… along with v9). The very basic entities that it is made of are” the publisher, the subscriber (obviously, isn’t it ?) and the properties (in other words entity which seats in between other two, don’t confuse it with massage queue… we’ll see afterwards about this ).

How things are passing?

One thread, the one which initiates the communication, publisher, creates and updates a propriety and the other one, the subscriber, listens for changes and get their current value.
Proprieties are stored internally as instances of TProperty class, defined in sproperty.cpp. They have three key attributes: Identity, Type and Security.

The identity is identified by 64 bits split in two halves: first 32 define the category and last 32 define
the key. A property is said to belong to a category, which is a standard Symbian OS UID (more about this when talking about Symbian UI’s). The key is a 32-bit value that identifies a specific property
within a category. There can be distinguished three types of properties: 32-bit value, contiguous set of bytes and Unicode text.

A property (some kind of system visible variable) can have also two security members: one for read operations and other for write operations. The identity and type of a property is the only information that must be shared.

There are six basic operations that can be performed on a property: define, delete, publish, retrieve, subscribe and unsubscribe. I will say briefly few words about each of them but I won’t go farther into details.

    Define – means to create a property variable and define its type and access controls, one thing to notice is that you’re not forced to define a property before accessing it; once the property is defined it persists until rebooting the system or deleting it (only the creator can perform a delete)
    Delete – consists in removing a property from the system.
    Publish – change the value of a property or update it; this can be achieved in two ways: by specifying the category and the key, either using a pre-attached RProperty handle, this guarantees instead a bounded execution time, making it suitable for high priority, real time tasks
    Retrieve – Get the current value of a property.
    Subscribe -Register for notification of changes to a property; If you subscribe to a property, you are requesting a single notification of when the property is next updated. The kernel does not generate an ongoing sequence of notifications for every update of the property value. Neither does the kernel tell you what the changed value is.
    Unsubscribe – Say that you no longer want to be notified of changes.

Publish and subscribe is probably the most important new IPC mechanism and the one with the most impact. It was created to solve the problem of asynchronous multicast event notification and to allow for connection-less communication between threads.

Personally I found the picture below very useful in getting a deeper understanding of Publish&Subscribe, especially when you want to trace the differences to Message Queues ITC.

Message Queues is an API that allows designers to break the connection while keeping the communication between two or more threads. In that sense two threads may communicate with one another without needing to set up connections to each other. This in effect breaks the synchronicity in the setting up the connections. All those things are making it different from Client/Server paradigm and what does it distinguish from the Publish and Subscribe paradigm is the fact that the identity of the recipient is not needed for communication.

A queue is generally created to handle messages of a given type of defined (fixed) length. The size of a queue, ie, maximum number of messages,
or slots, it can contain is defined and fixed when the queue is created. The size of message for which a queue is created, and the size of the queue is
arbitrary, being limited only by system resources. Queues can be of two types: local, visible only within the process, and global, visible to all processes.

Contrary to the connection-oriented nature of client/server IPC, message queues offer a peer-to-peer many-to-many communication paradigm. With the Message Queue API, threads may send messages to interested parties without needing to know if any thread is listening. Moreover the identity of the recipient is not needed for such communication.

There are five basic operations that can be performed on a message queue.

* Creating/opening a message queue
* Sending a message
* Receiving a message
* Waiting for space to become available in the queue
* Waiting for data to arrive in the queue

Find below a visual model of message-queues ITC.

A thread may request a queue whether it has space available to send messages as well as whether any messages are pending for delivery. Moreover a thread can interrogate the queue as to its message size. Additionally a thread may choose to wait on a queue until data or space become available. There is also the possibility to secure the communication by typing the queues, so only such specific messages can be received/send.

Whereas Publish and Subscribe is excellent for notifications of state changes (that are inherently transient), queues are good for allowing information to be communicated and transcend the sender’s state or lifetime.

A very useful resource about ITC or Inter-process communication means can be found here.
Also under developer.symbian.org there is a free on-line book available called Symbian Internals, which dives into the very intricacies of the OS itself (code-examples are provided as well as a cut down version of each significant class).

Advertisements

5 Responses to Inter-Thread Communication in Symbian

  1. Gluccactatt says:

    Hello Every body,

    I am new member right here

    I just lately discovered this place and so far i have found a lot of good information right here.
    I’m looking forward to connecting and contributing to the forum.

  2. venusesobn says:

    hi there! I am new to the board and just wanted to introduce myself 🙂

  3. acoungank says:

    Hello Every body,

    I am new member here

    I recently found this place and so far i have discovered lots of great information here.
    I’m looking forward to connecting and adding to the forum.

  4. kent says:

    Hello Every body,

    I am new member here

    I recently found this place and so far i have discovered lots of great information here.
    I’m looking forward to connecting and adding to the forum.

    • Hi there!
      Thanks for appreciations! It is really good to know that, somehow, somebody is “listening” you.
      Sorry for the “quite low” frequency of updates, but I recently got a new job and currently this is eating much of my time, at least until I get used with it.. and later .. bored with 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: