about pulse

Hi,

I have trouble with concepts of pulses.

In the manuals of qnx, it is said that pulse is asynchronization service
provided by QNX operating sytem. Furthermore, if multiple pulses are sent to
a channel without a thread waiting to receive them, the pulses are queued in
priority order. So where did pulses are buffered?

Such that, if one thread sends pulses continously to another thread,
however, the receiving thread is blocked due to some reasons. As a result,
is this pulse missed or is waiting on the channel till the receiver thread
is released and ready to receive it? If the receiving thread can accept
different kinds of pulses, so are these pulses buffered in the same queue or
different queues? And what is size of pulse queue if they are buffered in
the queue?

Moreover, between message-passing and pulses, which way is more safe and
fast for tasks communication?

Thanks

Belinda <yye@is2.dal.ca> wrote:

Hi,

I have trouble with concepts of pulses.

In the manuals of qnx, it is said that pulse is asynchronization service
provided by QNX operating sytem. Furthermore, if multiple pulses are sent to
a channel without a thread waiting to receive them, the pulses are queued in
priority order. So where did pulses are buffered?

Inside of the kernel; they are queued on a structure associated with the
channel, and the channel is a structure maintained within the kernel.

Such that, if one thread sends pulses continously to another thread,
however, the receiving thread is blocked due to some reasons. As a result,
is this pulse missed or is waiting on the channel till the receiver thread
is released and ready to receive it? If the receiving thread can accept

It is waiting; it is not missed.

different kinds of pulses, so are these pulses buffered in the same queue or
different queues? And what is size of pulse queue if they are buffered in
the queue?

There are a few interesting things that happen with pulses. First off, there’s
the fact that they are very tiny – 40 bits (32 + :sunglasses: plus some queueing overhead.
The other thing is that pulses can be compressed by the kernel. So, for example,
if thread A sends 750 of the same pulse, the kernel only keeps the pulse’s 40-bits
worth of value, and a counter set to “750”, which goes down by one each time the
pulse is handled by the thread associated with the channel…

Moreover, between message-passing and pulses, which way is more safe and
fast for tasks communication?

Pulses will certainly be faster, because there is (usually) much less data.
Safer? Well… that depends on what your goals are. In a networked environment,
last time I checked (someone will jump in if I’m wrong) certain types of
pulse delivery (and indeed MsgDeliverEvent in general) is not guaranteed.

If you want to transfer large amounts of data, you’ll probably want to set
up a shared memory segment with its own queues and notification structures,
and simply use a pulse as a “tap on the shoulder” to tell a thread to go
look in the shared memory. Since the pulse can carry 8+32 bits of data,
you could use the first 8 bits to tell you what kind of data is waiting,
and the remaining 32 bits to tell you where in the shared memory the data
is. Again, depends what you’re doing.

Cheers,
-RK


Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Belinda <yye@is2.dal.ca> wrote:

Hi,

I have trouble with concepts of pulses.

In the manuals of qnx, it is said that pulse is asynchronization service
provided by QNX operating sytem. Furthermore, if multiple pulses are sent to
a channel without a thread waiting to receive them, the pulses are queued in
priority order. So where did pulses are buffered?

The kernel allocates memory and queues them in kernel space, the
queue is associated with the receiving channel.

Such that, if one thread sends pulses continously to another thread,
however, the receiving thread is blocked due to some reasons. As a result,
is this pulse missed or is waiting on the channel till the receiver thread
is released and ready to receive it?

The pulse are not lost.

In general, the only time a pulse is lost is if you do a MsgReceive*()
and your received buffer is less than the size of a struct _pulse, in this
case, the pulse is discarded, and your MsgReceive*() will return -1.

If the receiving thread can accept
different kinds of pulses, so are these pulses buffered in the same queue or
different queues?

In general, if they are all sent to the same channel, they will be in the
same queue. (Most receiving processes only use one channel. But, you get
a queue per channel.)

And what is size of pulse queue if they are buffered in
the queue?

There is no arbitrary limit – entries are allocated on demand. Some
“compression” of identical pulses is done, if this will not change the
order of delivery. Degenerate cases can cause problems for QNX.

Moreover, between message-passing and pulses, which way is more safe and
fast for tasks communication?

Depends on what you are trying to do. Pulses and messages are intended
for different things. Pulse are generally used for notification –
“something happened”. Messages are used for moving data and getting
work done – “please give me data”, “please do something with data”,
or “please do something with this data and give me the results”.

Both are safe, both are moderately fast. A pulse is faster than a
message if you just want to notify. But, if you need to move 200
bytes from one process to another, a message pass will be faster
than using 50 pules.

If you want to move really large amounts of data around, it may
be worth looking at shared memory. Quite possibly using message
passing on top, for the inherent synchronisation.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.