when to lock a MibTable

[Frank Fock]

Hi Dave,

Calling start_synch/end_synch around MibTable::remove_row *is*
necessary! MibTable::fire_row_changed does synchronize
*other* MibEntry instances that are listening for row change
events of this MibTable.
This implies that a table cannot listen for its own row
events, because it otherwise would run into a deadlock when
adding or deleting rows.

Best regards,
Frank

Dave Mason wrote:
> Hi Frank,
> This is a quick follow-up to another answer you gave me a while back. 
> You once said that if I call MibTable::remove_row (oid) to delete a row 
> from a table, I should call table->start_synch and table->end_synch to 
> lock out other threads during the delete.  I took another look at the 
> remove_row code, and it calls fire_row_changed, which appears to do its 
> own start_synch and end_synch.  Are the extra start_synch and end_synch 
> in the user code necessary, or just an added precaution?  I see that 
> MibTable::add_row works the same way, I assume the answer holds for it 
> as well.  As before, I'm still on Agent++ v3.5.3a.
> 
> Regards,
> Dave
> 
> 
>