Fix a concurrency bug in the ranking reconsideration.

If we rely on mNotificationList to be sorted, then we cannot allow
records to change without a corresponding call to sort.  Currently
RankingFuture may modify records in a separate thread, while the sort
doesn't happen until later.  This creates a window for race conditions.

Instead, RankingFuture should record operations to be performed on the
record that will replayed later, in a transaction along with a sort.

We can't simply overwrite the old record completely because another
future may be concurrently modifying a different aspect of the record.
Two futures that attempt to modify the same aspect will be serialized
and the second will overwrite eventually the first.

Change-Id: I9223cabdc60f72d8e37e6d8119bea1e0127185c0
(cherry picked from commit 77d3e0d0297caca5358879d36e8ba77710eb8e82)

0 files changed, 0 insertions, 0 deletions