While the sending and receiving a message are blocking operations and it works pretty well in most cases, sometimes you will need a asynchronous way to send a message.

Notification is asynchronous (non-blocking) IPC mechanism which simply updates (bitwise-ORing) the notifications field of the destination task. When a task tries to receive a message, the kernel first checks pending (unreceived) notifications, and if exists, the kernel returns them as a message.

Note that notification IPC is just a bitfield update (just like signals in UNIX): it's impossible to determine how many times a same notification has been notified.

Why we need notifications?

Let's say that you're desiging a TCP/IP server and underlying device drivers:

              send a message
             when packet arrives
   Device  ----------------------->  TCP/IP
   Driver                            Server
     ^                                |
     |                                |
       send a message to emit packets

It looks an intuitive approach, however, what if the device driver tries sending a network packet when the TCP/IP server is trying to send a message to the driver? It would cause a deadlock because IPC operations are blocking.

The most important thing when you're writing a Resea application is: never have two task send messages each other as described in QNX's IPC documentation.

How can we avoid deadlocks in Resea? This is where notifications comes into play.

Notify & Pull Pattern

Instead of sending message each other, when TCP/IP sends some data to the driver, it notifies the driver asynchronously that there's pending data. When the device driver receives the notification, it pulls the pending data via message passing:

            2. request and receive
             the sending packet
   Device  ----------------------->  TCP/IP
   Driver                            Server
     ^                                .
     .                                .
         1. notify that new data is
          available asynchronously

See Asynchronous IPC for more detials.