Possible race conditions in table sharing if Sharing/unsharing/unregistering while managing/updating/accessing

[skliper]

Describe the bug
Related to #1493, no built in protection from possible race conditions with global table data if tables are shared/unshared/unregistered currently with other management functions from multiple tasks.

CFE_TBL_GetInfo example:

cFE/modules/tbl/fsw/src/cfe_tbl_api.c

Lines 1448 to 1454 in 82c1bd4

	/* Count the number of Access Descriptors to determine the number of users */
	HandleIterator = RegRecPtr->HeadOfAccessList;
	while (HandleIterator != CFE_TBL_END_OF_LIST)
	{
	NumAccessDescriptors++;
	HandleIterator = CFE_TBL_Global.Handles[HandleIterator].NextLink;
	}

CFE_TBL_Modified example:

cFE/modules/tbl/fsw/src/cfe_tbl_api.c

Lines 1562 to 1572 in 82c1bd4

	AccessIterator = RegRecPtr->HeadOfAccessList;
	while (AccessIterator != CFE_TBL_END_OF_LIST)
	{
	/* Only notify *OTHER* applications that the contents have changed */
	if (!CFE_RESOURCEID_TEST_EQUAL(CFE_TBL_Global.Handles[AccessIterator].AppId, ThisAppId))
	{
	CFE_TBL_Global.Handles[AccessIterator].Updated = true;
	}
	AccessIterator = CFE_TBL_Global.Handles[AccessIterator].NextLink;
	}

Note, looks avoidable if CFE_TBL_Register and CFE_TBL_Share happen at startup and shared tables don't CFE_TBL_Unregister. But still need to keep in mind blocking related to management and how updates work.

To Reproduce
Via inspection...

Expected behavior
No race. Add locks or disallow API use in certain system states. Consider if simplification is possible based on actual use cases.

Code snips
See above

System observed on:
NA - inspection

Additional context
Code review

Reporter Info
Jacob Hageman - NASA/GSFC