Improve uniqueness in resource IDs #924
Comments
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Oct 13, 2020
Use the entire resource ID space (16 bits) and do not immediately recycle ID values until the full space is used. Implement a generic routine to find the next available ID, and modify every resource ID allocation to use this routine. Where necessary, this also corrects for differences in argument checking and duplicate checking between the various resource types. All resource allocation procedures now have consistent argument checking, and will reject duplicate name creation for any resources that are also associated with names.
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Oct 13, 2020
Use the entire resource ID space (16 bits) and do not immediately recycle ID values until the full space is used. Implement a generic routine to find the next available ID, and modify every resource ID allocation to use this routine. Where necessary, this also corrects for differences in argument checking and duplicate checking between the various resource types. All resource allocation procedures now have consistent argument checking, and will reject duplicate name creation for any resources that are also associated with names.
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Oct 13, 2020
Use the entire resource ID space (16 bits) and do not immediately recycle ID values until the full space is used. Implement a generic routine to find the next available ID, and modify every resource ID allocation to use this routine. Where necessary, this also corrects for differences in argument checking and duplicate checking between the various resource types. All resource allocation procedures now have consistent argument checking, and will reject duplicate name creation for any resources that are also associated with names.
jphickey
added a commit
that referenced
this issue
Oct 21, 2020
Due to a merge the setting of this to its final value got moved. Need to use "Pending" value, not the one in the table record.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
In the event that a resource "A" such as an app/counter/pool etc is created, then deleted, then another resource "B" is created, the code will re-issue the same resource ID for "B" as was used for "A".
This means if a stale reference to "A" is stored somewhere, it silently now becomes an alias to "B". All validation/checks will pass.
Describe the solution you'd like
Should not immediately recycle ID values.
Additional context
This is the way OSAL already works, and is enabled by using abstract IDs.
With the recently introduced resource ID abstractions, it is no longer necessary to limit to the respective table size(s), because IDs are not directly used as table indices anymore. This means that a much larger set of potential ID values is available, and thus means that IDs of old/deleted objects can be different than the new objects while keeping table size the same.
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: