-
Notifications
You must be signed in to change notification settings - Fork 18
Notes on Software Engineering Issues and Practices
Using addresses as search keys can cause an ABA address-recycling bug. In many parts of the code we use addresses of objects to search for their presence in lists. This is susceptible to the ABA address-recycling bug. For instance:
- I allocate a StandardJob, which has address 0xAAAA
- I start an Alarm to let me know that that job has expired
- The job completes normally well ahead of the expiration
- I allocate ANOTHER StandardJob, which ALSO has address 0xAAAA because the heap allocator reuses the same location
- That other job runs, and at some point I get the "job expired" message from the Alarm for job 0xAAAA
In this way, I am mistaking an "old message that I should ignore" for a "oh no, a job has expired" message.
The way to fix this: create a unique sequence number for each StandardJob (static variable inside the constructor that gets incremented). Then, before sending the message, the Alarm could, for instance, check that the sequence number of the job at address 0xAAAAA has not changed. Or, the message could be sent regardless, and the recipient of the message would then do the check. In essence, the check is: "yes, there is a job at that address you're telling me about, but let me checked if it's really the job you mean".
The code was initially developed by people who hadn't touched C++ in up to decades, and so const isn't used enough, along with references, etc.