Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repetitive AppID lookups in CFE_SB_SendMsgFull #923

Closed
jphickey opened this issue Sep 30, 2020 · 4 comments · Fixed by #925 or #936
Closed

Repetitive AppID lookups in CFE_SB_SendMsgFull #923

jphickey opened this issue Sep 30, 2020 · 4 comments · Fixed by #925 or #936
Labels
Milestone

Comments

@jphickey
Copy link
Contributor

Describe the bug
SB has some code to filter an app's own messages via CFE_SB_PIPEOPTS_IGNOREMINE. This gets the appid and compares to the AppID of the pipe creator, and skips the destination if its a match:

if(PipeDscPtr->Opts & CFE_SB_PIPEOPTS_IGNOREMINE)
{
CFE_ES_ResourceID_t AppId;
CFE_ES_GetAppID(&AppId);
if( CFE_ES_ResourceID_Equal(PipeDscPtr->AppId, AppId) )
{
continue;
}
}/* end if */

The problem is that this is "inside the loop" of all destinations in the routing entry. So it will (potentially) call CFE_ES_GetAppId() multiple times. This also creates a double locking situation, because the SB lock is being held at the time this executes, and the ES lock needs to be acquired by CFE_ES_GetAppId()

Expected behavior
Code should query the caller AppID early, before taking the SB lock.

Additional context
The code works but is inefficient, and double locking is a potential deadlock.

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

@jphickey jphickey added the bug label Sep 30, 2020
@jphickey
Copy link
Contributor Author

I'm calling this a bug even though it runs due to the double lock and that it is a potential code standards issue - as (I think?) we are not supposed to create local vars inside the function code, only at the beginning?

@astrogeco
Copy link
Contributor

I'm calling this a bug even though it runs due to the double lock and that it is a potential code standards issue - as (I think?) we are not supposed to create local vars inside the function code, only at the beginning?

Do you have access to the style guide? Funny enough I stumbled on to this stack overflow discussion that discussed it. I'll need to go through the code standard and see where it mentions it.

@skliper
Copy link
Contributor

skliper commented Sep 30, 2020

3.7 - (6) "Function scope variable declarations shall precede any code statements. "

@jphickey
Copy link
Contributor Author

jphickey commented Sep 30, 2020

There are other examples of block-scope variables being used, such as here:

if (DestPtr->PipeId < CFE_SB_TLM_PIPEDEPTHSTATS_SIZE)
{
CFE_SB_PipeDepthStats_t *StatObj =
&CFE_SB.StatTlmMsg.Payload.PipeDepthStats[DestPtr->PipeId];
StatObj->InUse++;
if(StatObj->InUse > StatObj->PeakInUse){
StatObj->PeakInUse = StatObj->InUse;
}/* end if */
}

To clarify this is being declared in a block so it has block scope, not in a function scope. And they are at least at the beginning of the block, before code in that block.

Still, I think it is best to avoid the practice when possible, I consider it almost the same thing....

jphickey added a commit to jphickey/cFE that referenced this issue Sep 30, 2020
Move the AppID lookup to be early in the CFE_SB_SendMsgFull implementation.
Avoids double locking between SB+ES and avoids a block-scope local variable.
@astrogeco astrogeco added this to the 7.0.0 milestone Sep 30, 2020
astrogeco added a commit that referenced this issue Oct 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants