summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorRambo Wang <rambowang@google.com>2020-03-11 20:00:24 -0700
committerRambo Wang <rambowang@google.com>2020-03-13 18:55:03 +0000
commitccc118ec9b2d121d3f96b5c1247227ae9c7d5a8b (patch)
treea615ed26cf1476e0af7c52f2f7c52e803619c151 /tools/aapt2/java/JavaClassGenerator_test.cpp
parent6945c01f1ab27f820ca822fc8cc53e09d6ab344b (diff)
CellularDataService: mCallbackMap is not thread safe
The HashMap object mCallbackMap in CellularDataService is a shared resource between DataService's handler thread and CellularDataService's handler thread. The update operations (put and remove) has synchronization issue. This CL fixes the issue by letting CellularDataService shares the looper/handler thread of DataService (but keeping its own handler). And thus all the operations of mCallbackMap are handled serializally in DataService's handler thread. One alternative solution is to move all operations of the mCallbackMap into CellularDataService's handler thread to make it thread-safe. But it's difficult for close() method which need to clear mCallbackMap and shutdown the handler thread. The other alternative solution is to replace HashMap with ConcurrentHashMap for mCallbackMap. This do make mCallbackMap thread-safe but do not change the fact that it is still a shared resource between two threads. Bug: 151103522 Test: atest FrameworksTelephonyTests Merged-In: I7f5a507c2a79c7c77c5c2d7d3be147af80dc9f69 Change-Id: I7f5a507c2a79c7c77c5c2d7d3be147af80dc9f69 (cherry picked from commit ccf29801e2cbd48842ea91194453e50ae14125a3)
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions