avoid possible lock order issue with interested_remove

Ensure that Monitors aren't destroy()'d with an extra,
unnecessary, lock held.
This commit is contained in:
Michael Davidsaver
2017-11-29 09:48:54 -06:00
parent 82c689a7fd
commit 3dfdda667a
2 changed files with 12 additions and 8 deletions

View File

@ -82,6 +82,7 @@ void pdb_group_event(void *user_arg, struct dbChannel *chan,
mon.post(self->scratch);
}
PDBGroupPV::interested_remove_t temp;
{
Guard G(self->lock);
@ -93,10 +94,11 @@ void pdb_group_event(void *user_arg, struct dbChannel *chan,
self->interested_add.erase(first);
}
while(!self->interested_remove.empty()) {
PDBGroupPV::interested_remove_t::iterator first(self->interested_remove.begin());
self->interested.erase(static_cast<PDBGroupMonitor*>(first->get()));
self->interested_remove.erase(first);
temp.swap(self->interested_remove);
for(PDBGroupPV::interested_remove_t::iterator it(temp.begin()),
end(temp.end()); it != end; ++it)
{
self->interested.erase(static_cast<PDBGroupMonitor*>(it->get()));
}
self->interested_iterating = false;

View File

@ -61,6 +61,7 @@ void pdb_single_event(void *user_arg, struct dbChannel *chan,
mon.post(self->scratch);
}
PDBSinglePV::interested_remove_t temp;
{
Guard G(self->lock);
@ -72,10 +73,11 @@ void pdb_single_event(void *user_arg, struct dbChannel *chan,
self->interested_add.erase(first);
}
while(!self->interested_remove.empty()) {
PDBSinglePV::interested_remove_t::iterator first(self->interested_remove.begin());
self->interested.erase(static_cast<PDBSingleMonitor*>(first->get()));
self->interested_remove.erase(first);
temp.swap(self->interested_remove);
for(PDBSinglePV::interested_remove_t::iterator it(temp.begin()),
end(temp.end()); it != end; ++it)
{
self->interested.erase(static_cast<PDBSingleMonitor*>(it->get()));
}
self->interested_iterating = false;