Fix #673 and #677, update global locks

[jphickey]

Describe the contribution
Reworks the POSIX global lock implementation.

• Does not change the POSIX signal mask when locking/unlocking the global. Aside from being unnecessary, there was also a race condition in here (Fixes POSIX unnecessarily setting signal masks in global lock #673)

• Adds a condition variable to the global lock structure. In the event that there is more than task competing for access to the same object, this allows the second task to be woken immediately instead of polling for a change (Fixes Implement better way to wait for status change #677).

Testing performed
Build and run all unit tests
Build and sanity check CFE

Expected behavior changes
No longer changing signal masks repeatedly/unexpectedly. (may be relevant to some BSP/driver developers)

System(s) tested on
Ubuntu 20.04
RTEMS 4.11

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

[jphickey]

Only marked as draft because it requires a baseline which is not yet in main - will rebase once next baseline is settled.

[astrogeco]

CCB 2020-12-09 APPROVED

• Do we expect other platforms to support the condition variables from posix? There are "barriers" in RTEMS but they're not paired with mutex. VxWorks has binary semaphores but also suffers from the non atomic issue. These have a risk that the state can change in the midst of the call.
• RTEMS does have a posix layer that might include the needed functionality
• Caution against having a difference platform implementation for a minor performance gain
• Concerns that the polling and delay would result in taking more time for this operation than expected
• @jphickey open issue about this in VxWorks and RTEMS

[jphickey]

Rebased to main.

Also fixed an intermittent issue I found in testing where the mutex would not be released. There is a test case where a task gets deleted immediately after creation, and sometimes this would happen while it was still initializing and holding the table mutex. Solution is to add a cleanup handler around the pthread_cond_wait just like bin sems use, so if the task is deleted, the mutex also gets unlocked.

[astrogeco]

@jphickey I resolved a small conflict here, I'll do a squash-commit on this unless you want to rebase and force push.

[jphickey]

@jphickey I resolved a small conflict here, I'll do a squash-commit on this unless you want to rebase and force push.

Yes, I recall a small conflict with the #endif comment.

Does it really need a rebase though? Can't we just make a normal merge commit with the conflict resolved? Do you want me to do that in the integration candidate?

I don't like squashes at this point because it makes it hard to track what branches in my fork can be deleted (i.e. there is no specific git record of the merge, and git branch --merged doesn't report it, and so on).

[astrogeco]

@jphickey I resolved a small conflict here, I'll do a squash-commit on this unless you want to rebase and force push.

Yes, I recall a small conflict with the #endif comment.

Does it really need a rebase though? Can't we just make a normal merge commit with the conflict resolved? Do you want me to do that in the integration candidate?

I don't like squashes at this point because it makes it hard to track what branches in my fork can be deleted (i.e. there is no specific git record of the merge, and git branch --merged doesn't report it, and so on).

I suggested a rebase to avoid having f5b84da in the commit history.

Regarding the squash, I think github gives me the option to delete the branch after merging

[jphickey]

No worries about f5b84da we can avoid this either way.

Regarding deleting branches I also need to delete them on my local machine - not just the fork. I very much prefer not to break git branch --merged command.

I can easily/quickly push a merge commit to integration-candidate that fixes it. Or alternatively if you really prefer a rebase I can do that too but I'd prefer to do it myself as it keeps my local branches in sync with my fork branches.