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

CFE_ES_RunLoop increments the main task ExecutionCounter rather than the task that called it #567

Closed
jphickey opened this issue Mar 23, 2020 · 8 comments · Fixed by #1601 or #1619
Closed
Assignees
Labels
docs This change only affects documentation. enhancement
Milestone

Comments

@jphickey
Copy link
Contributor

jphickey commented Mar 23, 2020

Is your feature request related to a problem? Please describe.

Inside the CFE_ES_RunLoop() function itself, it looks up the MainTaskId of the caller and only increments that execution counter, not the execution counter of its own task record. This means no matter what child task actually calls this function, it implements the execution counter of the main task only.

Note that if the real main task is doing something else and also increments its own task counter, this is a race condition.

Describe the solution you'd like
I suggest one of the following:

  1. Just have CFE_ES_RunLoop() invoke CFE_ES_IncrementTaskCounter() to increment the counter for the task from which it was called. So if it gets called from a child task, then that child task gets incremented, not the main task. This is at least straightforward/consistent and avoids the race condition.
  2. Maintain a separate "app" exec counter which is incremented by CFE_ES_RunLoop (only), and use the CFE_ES_IncrementTaskCounter to account for other regular task activity.

Additional context
Noticed this when fixing #480 and it seemed rather odd/incorrect to be storing the ExecutionCounter where it is. This causes the code to jump to other entries in the table for the sole purpose of reading/updating this value, when it already had the correct app record to start.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

@jphickey jphickey self-assigned this Mar 23, 2020
@ejtimmon
Copy link
Contributor

FWIW I recently got some questions from app developers about this (wanting to know whether the exec counter should be incremented in child tasks) - the change suggested would clarify that. I did get the sense from those users that they wanted a way to track the execution of child tasks in addition to the main task.

@jphickey
Copy link
Contributor Author

@ejtimmon After initially writing this issue I then rediscovered that there is a function called CFE_ES_IncrementTaskCounter which increments the counter for the task context which invoked it.

So yes, there is actually the notion of a child task counter....

But then it is still unclear to me why the CFE_ES_RunLoop function would increment the counter for the main task of the app, rather than the task that actually invoked the function - this doesn't make sense, because if the main task also calls CFE_ES_IncrementTaskCounter() like child tasks do then it will get double incremented, or if a child task calls CFE_ES_RunLoop() then that activity will actually get accounted for in the main task (which is just plain wrong).

I suggest one of the following:

  1. Just have CFE_ES_RunLoop() invoke CFE_ES_IncrementTaskCounter() to increment the counter for the task from which it was called. So if it gets called from a child task, then that child task gets incremented, not the main task.
  2. Maintain a separate "app" exec counter which is incremented by CFE_ES_RunLoop (only), and use the CFE_ES_IncrementTaskCounter for regular task activity accounting.

At the very minimum, it is probably at least worth a note in the documentation of CFE_ES_RunLoop that it is incrementing a task counter (whichever one it is) because the documentation doesn't seem to mention it at all, and this could certainly confuse someone (it confused me...).

Probably worth a quick discussion to see what others think...

@jphickey jphickey changed the title ExecutionCounter should be associated with an app, not a task. CFE_ES_RunLoop increments the main task ExecutionCounter rather than the task that called it Mar 24, 2020
@jphickey jphickey added question CCB:Ready Ready for discussion at the Configuration Control Board (CCB) labels Mar 24, 2020
@ejtimmon
Copy link
Contributor

Whenever a decision is made, we should also add guidance to the App Developer's Guide.

@astrogeco
Copy link
Contributor

astrogeco commented Mar 25, 2020

CCB 2020-03-25: Discussed, will have telemetry impacts based on app vs task counter. Will also affect Health and Safety's behavior. Behavior needs to be documented in users guide, document that "run loop" should be called from main task.

@astrogeco astrogeco removed the CCB:Ready Ready for discussion at the Configuration Control Board (CCB) label Mar 25, 2020
@skliper
Copy link
Contributor

skliper commented Jan 11, 2021

Is this needed for Caelum? Should we touch on again in CCB?

@jphickey
Copy link
Contributor Author

Note that previous changes in this area did in fact change CFE_ES_RunLoop to call the CFE_ES_IncrementTaskCounter to increment the counter. Simply put - it has to be this way because having any task increment a counter other than its own (i.e. the old way) would be a race condition. So this is not only simpler - just one common function to increment exec counter - it is also safer.

If guidelines/templates were followed this is no effective change because CFE_ES_RunLoop is called from the main task - so its the same counter. But if guidelines/templates were not followed and this is called from a child task then it will increment the counter of the child task, not the main task.

@jphickey
Copy link
Contributor Author

If anything we should just update the documentation of CFE_ES_RunLoop to indicate this -- that it increments the task execution counter of the task that called it, and is expected to be invoked from the "main" task of a CFE application, as part of that app's main loop.

@skliper skliper added the docs This change only affects documentation. label Jan 11, 2021
@skliper skliper added this to the 7.0.0 milestone Jan 11, 2021
@skliper
Copy link
Contributor

skliper commented Jan 11, 2021

Implementation change addressed by #598. Remaining work here is to update documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs This change only affects documentation. enhancement
Projects
None yet
4 participants