next up previous contents
Next: Process Models for Up: Protocols and Sessions Previous: Operations on Session

Asynchronous versus Synchronous Protocols

As described so far, the x-kernel supports asynchronous protocols---protocols that do not block waiting for a reply from their peer. Some protocols, however, are synchronous---the caller blocks until a reply can be returned. Clearly, the xPush/xDemux/xPop paradigm just described is not going to work for synchronous protocols since it makes no provision for a return value. The x-kernel accommodates synchronous protocols by providing a parallel set of operations for sending and receiving messages:

XkReturn xCall(Sessn session, Msg *request, Msg *reply)

XkReturn xCallPop(Sessn session, Msg *request, Msg *reply, void *hdr)

XkReturn xCallDemux(Protl hlp, Sessn session, Msg *request, Msg *reply)

The key difference, of course, is that each operation now returns a reply message ( reply); for clarity, we refer to the message given as an argument as request. The operations are synchronous in the sense that each cannot return until the reply message is available.

So far so good: some protocols are purely asynchronous (they export xPush, xPop and xDemux operations), and some are purely synchronous (they export xCall, xCallPop and xCallDemux operations). However, if all protocols were either asynchronous or synchronous, then the entire protocol graph would have to consist of only asynchronous or synchronous protocols---an asynchronous protocol can only call xPush on an adjacent protocol, meaning it could never be composed with a synchronous protocol.

Fortunately, there can be hybrid protocols that are half synchronous and half asynchronous. This does not mean that they support all six operations, but rather they look like a synchronous protocol to higher level protocols, and like an asynchronous protocol to lower level protocols. Such a protocol supports the xCall operation rather than xPush on top, while from below, it still supports the asynchronous xDemux/xPop interface, that is, it turns an underlying asynchronous communication service into a synchronous communication service. It does this by having the sending process (caller) block on a semaphore waiting for a reply message.



next up previous contents
Next: Process Models for Up: Protocols and Sessions Previous: Operations on Session



Larry Peterson
Wed Feb 21 13:58:06 MST 1996