I have one non-PhAB process and one PhAB process. I would like to send data back and forth between these process. I don’t think I can just use regular msgsend/msgreceive or mq_send/mq_receive. What is the proper method in this case? My non-PhAB is running at a higher priority than my PhAB process, so I don’t want priority inversion, and don’t want y non-PhAB process to be blocked waiting for reply.
Thanks
There is not enough information in here “send data back and forth” is pretty vague.
Typically a GUI will poll the other program and/or request notification of event. Hence it’s the PhAB app
that does the send and the real-time program replies with data, if any.
Personnaly I’ve never used mq or mqueue.
You need to be a little more specific about the data going back and forth. What data? Where does it come from? Which process gets it first? Mario suggests a good place to start. It is likely that your non-GUI program is a resource manager. The Gui program opens the resource and then either sends a request for data, or the data itself. If the data originates in the Gui program, then it is easy, because the send occur when the data is ready. If the data originates in the non-Gui program, then either the Gui program will poll, or somehow be notified. Various options exist. For example, you could create a thread in the Gui program that does a send, and waits for the reply when data is ready.
Generally speaking, resource managers run at the priority of their client sender, at least when doing their bidding. This is what prevents prevents, or at least mitigates priority inversion. The resource manager may have other work to do that needs to be done at a higher priority. The might occur in another thread.
It is possible this model is not adequete for your application, so tell us more.
ok, non-phab app is not a resource manager, but I guess i could make it one. The data is sent from the non-phab process to phab app process. I don’t like the idea of polling, so I guess I am going for requesting notification of event. Is creating input handler in PhAB process what you guys are suggesting? Also the data I am trying to send is a custom structure type. In this case I guess the Non-PhAB process can send data when ever, and the PhAB process can handle this message when it can.
Hmm I guess I forgot about non-phab being blocked in this case, so I guess i need to do asynchronous msg send or receive. Also can you tell me the default size of the message buffer? My data structure might get big and I am worried that some day it might be bigger than the message buffer size. I know I can use PtResizeEventMsg() in PhAB to increase this buffer size but is there a similar function to increase the message buffer size for message passing between two non-phab process?
You are asking for a tips about detailed implementation but you don’t give detail on the task to be performed, msg size, message rate, etc. I can only make vague suggestion.
“Hmm I guess I forgot about non-phab being blocked in this case”
That is why the PhAb should be the only one sending message.
“I guess i need to do asynchronous msg send or receive”
There is no such thing a asynchronous receive
“Also can you tell me the default size of the message buffer?”
Buffer size is irrelevant, the message doesn’t have to be received in one big chunk, you can call MsgRead to read the rest of the message in a separate buffer. Message can be as big as there is available ram. The fact that you are asking the question seems to indicate you are not yet 100% familiar with all the features and concept of message passing. I suggest you do some more reading before committing to a design.
Building the GUI so that it only send message or requestion notification of event as MANY advantages. First if the GUI isn’t there then the non-photon app doesn’t need to handle that scenario. You can start Multiple instances of GUI taking advantage of QNX networkin (sales people usually love that…) If the non-photon app is build as a resmgr, handling notification for more then 1 process is no big deal.
Async messages have the disadvantage, that you can’t return error code. When the message is sent you have no mean of knowing if the destination received the message or not. For example the message could be malformated and you wouldn’t know about it. You need extra messages to get status or rely on some watchdog time out feature. If receiver can’t keep up you could feel ram or loose messages. Using async often create a who new set of problem.
Yes, I am still in the design stage and that’s why I don’ t have too much details yet. The msg size is still unknown, but I know that it can get big. I know you can use MsgRead for messages that are bigger than the buffer size but I figured that it would be clean if I just match the buffer size to the message size since the message size is always the same. The message rate is fairly slow, maybe 1 message every 0.5s on avg. Yes, I could now see the advantage of GUI sending the msg and I like the idea of requesting notification of events.
I just thought that to build my non-phab process as a resource manager might be an over kill since all it has to do is send some data every 0.5s to the GUI app without being blocked. Most of the data crunching is done in non-phab process and GUI app only needs the data for displaying. Therefore, as soon as GUI receives the message from non-phAB process, it can reply right way even before displaying.
Ok, so the data information is traveling in the opposite direction, from the non-Gui to Gui program. Yes you could create an input handler, and have the Gui program send messages. This might be ok, but you didn’t tell us where the data was coming from. The problem is that non-gui program could block, although briefly. It might have to wait for the Gui process to finish what it is currently doing, and also wait for other, processes with priorities lower than the non-Gui, but >= the Gui to finish. This is a form of priority inversion that is almost never seen.
If the data coming into the non-Gui program is queued at its source, this is not a problem, but assuming it is not, there are two ways I can think of off hand to handle this.
Create a delivery thread in your non-Gui program. All it does is wait for data in a buffer, and when it finds it, send to the the Gui program.
Reverse the flow. Have the non-Gui program wake the Gui program up with, either with a signal (not recommended) or a pulse (recommended).
When the Gui program wakes up, it sends a request message to the non-Gui, and the Reply transports the data.
For this structure, you do NOT want to make your non-Gui program a resource manager, unless you reverse the flow of data. If the non-Gui process is sending messages, you definitely can block, although there is nothing you’ve mentioned so far that would make that a bad thing.
So far you’ve given no particular reason why the non-Gui process should have a higher priority. Usually we want Gui processes to get as much cpu as possible, since it gives the user a nicer interface. If you give the non-Gui process a higher priority it will tend to make the interface sluggish. If you give it a lower priority, it will not lose much ground unless your Gui is working very hard.
the reason non-gui process is in a higher priority is because it does image processing from a live camera in real-time. For us, GUI can hang a little, or even fail to display data once in while if it comes down to that. We are willing to Sacrifice GUI response time to real-time processing time.
Well you really have a lot of choices. Since missing a frame is ok, I would definitely have the image processing go at a lower priority.
You didn’t specify the nature of the data to be display. But I would go with this. Non-GUI program runs high priority . The GUI request notification for new data to the non-gui thread. When the non-gui program has process the data it makes a copy of it (what ever that data is, image, computation, results etc) , and sends the notification even to the GUI program (or any program for that matter). Then the GUI send a message to get that copied data back in the reply.
Yhe GUI may block waiting for the non-gui to reply, because he could be busy doing stuff. How long depends on how long the non-gui program takes to process that and come back in a receive mode. In theory you could have a second thread in the non gui program to deal with this, but it wouldn’t make any difference. See the NON-GUI program is running at high priority, hence while it’s running the GUI program can’t run thus can’t send the request! And that’s the way you want it to make sure the real-time part of it is respected. The second thread in the NON-GUI would make sense in a multiple CPU/CORE scenario though!
The data flow in one direction only, GUI ask for notification, non-gui sends it, GUI does a send, and non-GUI replies with data. Clean, lean and mean. Easy to understand, easy to implement, easy to debug. Very flexible (can have multiple GUI running at once). Can easly support feature like “pause” in the GUI without any need to introduce intelligence in the NON-GUI. Can start and stop GUI at will without disrupting real-time (nice for update ,experience shows that GUI gets updated a lot)
Thanks Mario, as always.
My pleasure, definitely more interesting then getting a USB mouse to work or cases of RTFM.
My late 2cents.
I built a data collection system where data generator placed binary structs into an mqueue. The GUI simply opened the mqueue as a regular file handle and then added an input handler for the photon loop.
This worked very well. The queueing was handled by the mqueue so neither side had to deal with handshaking. The only downside was that the data generator side would block when the mqueue filled up. This actually never happened in practice - I made the queues 10k messages in length and they never get more than 10-15% full.
All in all the mqueue approach is a very simple and robust solution (network transparent too).
And the coolest part? You can stick ‘filtering’ apps in the middle, connecting and filtering the mqueues almost ad hoc.
If you don’t need networking you can use mq instead (and the mq lib) they use async messaging and are much faster.