Timer "reconfig" tests do not work on RTEMS or VxWorks

[jphickey]

Describe the bug
The "reconfig" tests were added to verify that timer config calls from the context of a timer callback are rejected. Unfortunately the underlying mechanism that allows this to happen only works on POSIX (via the pthread keys, which can do this). On RTEMS and VxWorks, the mechanism which gets the task ID (OS_TaskGetId_Impl) doesn't return the timer ID when called from a timer task.

To Reproduce
Run timer tests on VxWorks or RTEMS, timer reconfig tests will fail.

Expected behavior
Test should pass.

System observed on:
MCP750 VxWorks 6.9
RTEMS 4.11.3

Additional context
Might be fixable on RTEMS but probably difficult to fix on VxWorks. May want to consider just skipping this test?

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

[jphickey]

For the record here is a trace of the test case:

[BEGIN] 06 TimerReconfig
[ FAIL] 06.001 ut_ostimer_timerio_test.c:87 - OS_TimerCreate(&timerId, "reconf", &g_clkAccuracy, UT_os_othertimercallback1) (-15) == OS_ERR_INCORRECT_OBJ_STATE (-35)
[ FAIL] 06.002 ut_ostimer_timerio_test.c:89 - OS_TimerAdd(&timerId, "reconf", g_timerIds[1], UT_os_othertimercallback2, NULL) (-15) == OS_ERR_INCORRECT_OBJ_STATE (-35)
[ FAIL] 06.003 ut_ostimer_timerio_test.c:90 - OS_TimerDelete(timerId) (0) == OS_ERR_INCORRECT_OBJ_STATE (-35)
[ FAIL] 06.004 ut_ostimer_timerio_test.c:91 - OS_TimerSet(timerId, 100, 100) (-16) == OS_ERR_INCORRECT_OBJ_STATE (-35)
[ FAIL] 06.005 ut_ostimer_timerio_test.c:92 - OS_TimerGetIdByName(&timerId, g_timerNames[7]) (-17) == OS_ERR_INCORRECT_OBJ_STATE (-35)
[ FAIL] 06.006 ut_ostimer_timerio_test.c:93 - OS_TimerGetInfo(timerId, &reconf->Prop) (-16) == OS_ERR_INCORRECT_OBJ_STATE (-35)
[  TTF] 06.007 ut_ostimer_timerio_test.c:278 - OS_TimerDelete(g_timerIds[2]) (-16) >= OS_SUCCESS
[  END] 06 TimerReconfig        TOTAL::7     PASS::0     FAIL::6     MIR::0     TSF::0     TTF::1     N/A::0

[skliper]

So the negative test fails in a different way, such that you still can't reconfig from within the context of a callback? Is this behavior dependable/by design? If so maybe just adjust the test to look for != OS_SUCCESS, or branch based on the first return (or the Get ID behavior) and check appropriately?

[jphickey]

Not quite, it is allowing the call.... which is technically not safe (it may double-take a mutex or change a linked list that is actively being traversed).

Error -15 is OS_ERR_NAME_TAKEN - this is because the attempt uses the same timer name (technically an overload, which another issue, but is easy to fix). Note that the OS_TimerDelete() actually succeeded.

My recommendation is to just better document the fact that the Timer/Timebase configuration API must not be invoked from the context of a timer. I thought it was documented, but reviewing the documentation now, I don't see it stated as clearly as it should be.

This whole check/test is only to save users from themselves and catch the programmer's error, but there's only so much that can be done in a practical sense. I would hesitate to change anything substantial at this point, for something that is a programmer error to begin with.

[skliper]

Then I'm in favor of skipping the test for RTEMS and VxWorks. I agree it's really an optional test (as-in - not verifying a "requirement") since as long as the API's are documented correctly it would be a violation of the API to attempt using these APIs in that context.

[jphickey]

Unfortunately we don't have an OSAL OS type macro (e.g. _POSIX_OS), only a PSP type macro (e.g. _LINUX_OS_). Easy enough to add though, and may be useful.