Fix #1021, resolve discrepancies between task API and unit tests

[jphickey]

Describe the contribution
Ensures correlation between the unit-tests and documented return values for the OSAL task API.

Fixes #1021

Testing performed
Build and run unit tests, re-run cross reference script to confirm

Expected behavior changes
All documented return values are tested or noted that they cannot be tested in functional test

System(s) tested on
Ubuntu

Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.

[skliper]

OS_TaskCreate - should test NULL stack address case (allocate from heap)
OS_TaskInstallDeleteHandler - check that delete handler actually gets called
OS_TaskDelay - add a check the delay actually delays? we depend on this working all over the place but I never see it actually checked
OS_TaskPriority - add a check that setting priority is actually respected
OS_TaskGetId - automate this check, pass in the pointer to the ID?
OS_TaskFindIdBySystemData - needs test

[skliper]

I suggest we hold off on this one until @jphickey and I have a chance to discuss

[jphickey]

Here's my take:

• OS_TaskSetPriority: No real easy way to check this in the current API, we would have to confine multiple tasks to the same CPU. As long as tasks are allowed to float among SMP CPUs, a lower priority and a higher priority task can run at the same time. Once we can assign affinity then the priority should be more verifiable. (except when permissive mode is used....)
• OS_TaskFindIdBySystemData: As noted in the comment, there is no way to get the "system data" that this depends on. This is only used by the PSP, where that info was acquired externally/outside of the OSAL API, to do the reverse lookup. Hence why the test only checks the errors right now.
• OS_TaskGetId: This is checking the returned value matches the expected ID. I am not sure what is being requested on this one.
• OS_TaskDelay: I suppose we can add a call to OS_gettime before and after, then look at the difference

[jphickey]

Commit 2d7d575 adds a check for OS_TaskCreate with NULL stack (dynamically allocate), checks that the task delete handler was invoked, and confirms that OS_TaskDelay actually delayed by comparing with OS_GetLocalTime.

[skliper]

@astrogeco @ejtimmon Since priority/scheduling testing is pretty much impossible to verify in a generic sense (without system/configuration knowledge), how about extending the OSAL example work to include a sample test that could confirm the MCP750 specific system setup (single core, whatever task scheduling is used)? So this wouldn't be a built-in open-source OSAL unit test, but could be used to show things work as expected on the MCP750. Would be great if this could eventually be extended to include a multi-cpu test, linux and RTEMS... but will still be system/configuration dependent. I'll mark/report testing of priorities and scheduling as a project/distribution test responsibility and not confirmed generically using OSAL unit tests.

[skliper]

Concur w/ all responses, fixes. Good to go. Note OS_TaskGetId comment was stale, so no longer applicable.

[jphickey]

If we resurrect the tasking-example as has been discussed, that might be a good place to demonstrate priorities.

I also thought we could check semaphore priorities. That is, if we create a low priority task first, let it block, then create a high priority task, and have it block on the same sem. If we then give the sem, only the high priority task should wake up. If we give it a second time then the low priority task should wake up. This would confirm priority-based semaphores which IIRC we are using, if the sem was configured as a FIFO then it would fail this test.

That test case could theoretically be done in the current tests but we would likely have to bypass it when OSAL_CONFIG_DEBUG_PERMISSIVE_MODE is enabled.

Also, the OS_task_prop_t structure has a "priority" member in it, which we can check. However, this still gets set even if OSAL_CONFIG_DEBUG_PERMISSIVE_MODE is enabled. Might want to modify this so it reflects the real priority as programmed into the OS Scheduler, then we can use this field to gauge the behavior to expect from other calls.

[jphickey]

Re-Pushed to correct commit message typo and squash commits where necessary

[skliper]

I also thought we could check semaphore priorities....

Good suggestion! Could you submit a new issue?

That test case could theoretically be done in the current tests but we would likely have to bypass it when OSAL_CONFIG_DEBUG_PERMISSIVE_MODE is enabled.

Isn't there a set of user level priorities that do still work in permissive? Can we stay in that range?

Also, the OS_task_prop_t structure has a "priority" member in it, which we can check. However, this still gets set even if OSAL_CONFIG_DEBUG_PERMISSIVE_MODE is enabled. Might want to modify this so it reflects the real priority as programmed into the OS Scheduler, then we can use this field to gauge the behavior to expect from other calls.

Good suggestion/update! Could you submit a new issue?

[jphickey]

Submitted issue #1059 for above