Can you wait a little bit faster?

I was having a conversation with a customer the other day who was very concerned about a pidin listing where he was seeing something like the following:

# pidin 
     pid tid name               prio STATE       Blocked 
       20   1 server_app             255o RECEIVE    1 
       20   1 server_app             10o  RUNNING 
       20   1 server_app             255o RECEIVE    1 
       32   1 client_app              10o REPLY         20 
       32   2 client_app              10f NANOSLEEP 

He was concerned because most of his system generally operated at priority 10 and if there were tasks that were at priority 255, then wouldn’t those other tasks be starved out and never get a chance to run!?

Of course if you take a few minutes to reflect on what is really being displayed then peace and calm return quite quickly to the world. 

The threads that are all marked as being high priority are all in blocking states.  That is to say that they are not RUNNING, nor are they wanting to run and in the READY state.  In fact they are all blocked waiting for some other sort of event to occur or non-CPU resource to become available.  While their reported priorities are high they are not going to interfere with the operation of the system … at least not until they transition to a RUNNING or READY state.   In the case of threads which are RECEIVE blocked such as is the case here, unless the communication channels were created specifically to avoid priority inheritance, the receive thread will end up READY/RUNNING at the priority of the sending client.

If that is the case you may wonder, why have pidin report the priority information on blocking states at all if it is just going to cause people this sense of panic and trigger these types of false alarms?

Well the information can be insightfull since in most blocking scenarios, the thread was READY or RUNNING prior to being blocked and as such the priority gives a hint to what they might have been doing.  Also in the case of priority inheritance states (MUTEX, SEND) then you can better see who is causing priorities to be automatically shifted in the system.

In this case, 255 was a curious number to be seeing and we eventually traced it back to their code where they were generating asynchronous pulse events to a server, but the pulses were not being properly initialized and were picking up junk off the stack and setting bad priorities … hence the 255 value. 

QNX Coding Tip of the Day:  Don’t initialize sigevent‘s using the member values, use the SIGEV_* macros!



3 comments so far

  1. Mario on

    Talking about pin. I’m curious what is the rational for the existence of pin and sin, each with half the option of the other?

    Sounds like somebody forgot about them both ;-)

  2. sendreceivereply on

    Not forgotten, more of a race to see who could get their functionality in where. Since Neutrino (QNX6) is really quite a different animal under the covers from QNX4, a whole new tool was needed for showing the state of the system. The sin tool (system information) was ported in the hopes that its functionality “would just map”, but it didn’t.

    With the 6.3.2 release, you should find nearly everything that the sin utility under QNX4 provided now rolled into the Neutrino pidin utility.

  3. Mario on

    I just read the “use” output of both program and realized that indeed pidin can do everything sin can. I didn’t realized it because I was used to typing command like:

    sin args but when i tried pidin args it didn’t work that’s because there is no s to arg. Same with a other commands. A case of RTFM.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: