Multi Threaded Resource Manager

The situation that I am trying to resolve is as follows:

I have designed a multi threaded resource manager that reads and writes
from a pipe. During the initialization of the resource manager, I use
“select_attach” to let the RM notify the handler as and when there is data
available in the pipe and waiting to be read.

when the function handler apecified in the select_attach call gets
triggered by the RM, it tries to read a certain number of bytes from the
pipe. For some reason, assume that there is not enough data in there to
satisfy the read request completely . This leads to a partial read that
gets buffered, lets say globally so that it can be shared by other threads
of the RM.

Next time. when the data arrives, the RM would again call the function
handler specified in the select_attach call. However, there is no
guarantee that this function handler would execute in the context of the
same thread that performed the partial read in the penultimate execution
of the select handler.

I data integrity is to be preserved, and to make my life easier as a
designer, I would expect some control on the thread pool manager to
guaranteee that subsequent select handler goes to the same thread in a
scenario explained as above. However, this could be a wishful thinking
because I am trying to figure out if there exists any control like this in
QNX 6.3 release. Alternatively, I would have to model the buffer meant for
holding the read data as a state machine that could keep track of
conditions where the last read was not completely successful. But there is
a problem with this approach too. The select handler has to deal with
variable size read operation and it does not have a priori knowledge of
the size of the incoming buffer.

How would QNX experts deal with a design problem like this?

Tanmay.

Tanmay Kishore <tkishore@ditechcom.com> wrote:

The situation that I am trying to resolve is as follows:

I have designed a multi threaded resource manager that reads and writes
from a pipe. During the initialization of the resource manager, I use
“select_attach” to let the RM notify the handler as and when there is data
available in the pipe and waiting to be read.

when the function handler apecified in the select_attach call gets
triggered by the RM, it tries to read a certain number of bytes from the
pipe. For some reason, assume that there is not enough data in there to
satisfy the read request completely . This leads to a partial read that
gets buffered, lets say globally so that it can be shared by other threads
of the RM.

Next time. when the data arrives, the RM would again call the function
handler specified in the select_attach call. However, there is no
guarantee that this function handler would execute in the context of the
same thread that performed the partial read in the penultimate execution
of the select handler.

I data integrity is to be preserved, and to make my life easier as a
designer, I would expect some control on the thread pool manager to
guaranteee that subsequent select handler goes to the same thread in a
scenario explained as above. However, this could be a wishful thinking
because I am trying to figure out if there exists any control like this in
QNX 6.3 release. Alternatively, I would have to model the buffer meant for
holding the read data as a state machine that could keep track of
conditions where the last read was not completely successful. But there is
a problem with this approach too. The select handler has to deal with
variable size read operation and it does not have a priori knowledge of
the size of the incoming buffer.

No, there isn’t such a control, but, well, I’m trying to figure out why
or how it matters that the same, or a different thread, is getting the
data from the queue.

How would you deal with it if you knew it was the exact same thread
each time? That is, how does knowing it is the same thread help you
to deal with it?

But, yes – if you are using anything that is stream oriented
(pipe, tcp socket, serial port) to deliver data that you consider
to be “packetized” or to have message boundaries, then you do have
to track partial/whole reads of the data.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com