when to lock a MibTable

[Dave Mason]

Hi,
This leads to a quick follow-up.  I'm adding or deleting a row inside a 
method as required.  Immediately before and after the table operation I 
do a table->start_synch() and end_synch()  as you mention.  To delete 
the rows, however, I need to call another method to scan through the 
whole table till I find the row with columnar values that match my 
criteria, then return a row pointer.  It appears I should use 
table->get_rows_cloned() to read the rows.  That method also calls 
start_synch() and end_synch().  Since I already called start_sync() 
before I get_rows_cloned(), will this make get_rows_cloned() block? 
 Also, since I want to return the row pointer, will it be wrong to 
return the one from get_rows_cloned, because it's a clone and not the 
real one?  I believe your answer will be yes - in that case, should I 
return the Oid of the index, from row->first()->get_oid(), and then use 
table->find_index(oid) to get the row pointer to delete?  (The index is 
the first column in my table.)

Thanks,
Dave

Frank Fock wrote:

> 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
>>
>>
>>
>
>
>
>
>

-- 
--------------------------------------------------------------------------------
Dave Mason  (817)481-4412 x139 voice, (817)481-4461 fax, dmason at transat-tech.com
Transat Technologies                180 State St, Suite 240, Southlake, TX 76092
Integrating 3GSM and WLAN                            http://www.transat-tech.com
--------------------------------------------------------------------------------