logd: clarify release_Locked() for static analyzer

release_Locked() is called with a reference count and threadRunning,
the static analyzer can not tell this and estimates that a call to
delete this will occur. So let us invent a new call
release_nodelete_Locked() to ensure it is clear we will not be
arranging a delete this in the context of this code path. The
delete this will follow in the immediate codepath in this function
after threadRunning is cleared, and decRef_Locked() is called.

Change will also remove any developer FUD regarding release_Locked()
usage at this location.

SideEffects: None

Bug: 27434831
Change-Id: I91b060b2dadc72cc449fa381c934afb577bee037
This commit is contained in:
Mark Salyzyn 2016-03-01 14:59:32 -08:00
parent 48d930d0a9
commit 0ecdec7a09
2 changed files with 8 additions and 2 deletions

View file

@ -90,7 +90,7 @@ void LogTimeEntry::threadStop(void *obj) {
while(it != times.end()) {
if (*it == me) {
times.erase(it);
me->release_Locked();
me->release_nodelete_Locked();
break;
}
it++;

View file

@ -75,7 +75,13 @@ public:
void triggerSkip_Locked(log_id_t id, unsigned int skip) { skipAhead[id] = skip; }
void cleanSkip_Locked(void);
// Called after LogTimeEntry removed from list, lock implicitly held
// These called after LogTimeEntry removed from list, lock implicitly held
void release_nodelete_Locked(void) {
mRelease = true;
pthread_cond_signal(&threadTriggeredCondition);
// assumes caller code path will call decRef_Locked()
}
void release_Locked(void) {
mRelease = true;
pthread_cond_signal(&threadTriggeredCondition);