[AGENT++] Agent++ Thread Safety

[Megan Smith]

Hi Frank,

In the second scenario, however, it is then possible for two different
tables to be modified concurrently.  If this is so, then isn't it possible
that the static variable _target_item in avl_map.cpp for example is being
used by two different tables concurrently without any locking?

Thank you,
Megan


On 5/21/08, Frank Fock <fock at agentpp.com> wrote:
>
> Hi Megan,
>
> Both version are correct depending on the
> usage scenario:
>
> If an existing object (i.e., row,table,leaf) is
> about to be deleted, you need:
>
>  mib->lock_mib();
>  table->start_synch();
>  ..some code modifying table content..
>  table->end_synch();
>  mib->unlock();
>
> If you will only modify an object's content or
> add a row, for example, then
>
>  mib->lock_mib();
>  table->start_synch();
>  mib->unlock();
>  ..some code modifying table content..
>  table->end_synch();
>
> is sufficient.
>
> Best regards,
> Frank
>
> Megan Smith wrote:
>
>> Hi Frank,
>>
>> Thank you for your quick response.
>>
>> In the documentation for mib->lock_mib() the mib lock is only held until
>> the
>> mib object lock is acquired:
>>
>> "While processing a (sub-)request the locking scheme is as follows: 1.
>> This
>> MIB lock is acquired. 2. The MIB object is identified, which is
>> responsible
>> for processing the sub-request. 3. The MIB objects lock (
>> MibEntry::start_synch()<
>> http://www.agentpp.com/doc3.x/classThreadManager.html#42bcd26c71747a3d01afd2a407b7f12e>)
>>
>> is acquired. 4. The MIB lock is released. 5. The sub-request is propagated
>> to the MIB object. 6. When finished, the MIB objects lock is released."
>>
>> But the procedure you just suggested:
>>
>> mib->lock_mib();
>> table->start_synch();
>> ..some code modifying table content..
>> table->end_synch();
>> mib->unlock();
>>
>> doesn't unlock the mib itself until the last step.  Which one is correct?
>> Or are they for different situations?
>>
>>
>> Thanks!
>> Megan
>>
>>
>> On 5/20/08, Frank Fock <fock at agentpp.com> wrote:
>>
>>> Hi Megan,
>>>
>>> You are probably on the wrong track here. The AVL
>>> trees should not be modified in the AGENT++ code
>>> concurrently anywhere.
>>>
>>> Such modifications have to be protected by
>>>
>>> mib->lock_mib();
>>> ..some code modifying mib registration (AVL tree)..
>>> mib->unlock_mib();
>>>
>>> or
>>>
>>> mib->lock_mib();
>>> table->start_synch();
>>> ..some code modifying table content..
>>> table->end_synch();
>>> mib->unlock();
>>>
>>> Best regards,
>>> Frank
>>>
>>> Megan Smith wrote:
>>>
>>> Hi,
>>>>
>>>> I posted this a few weeks ago and haven't heard any response yet.  We
>>>> are
>>>> using agent++ and have been experiencing segmentation faults from some
>>>> corrupted memory in the mib tables during highly multi-threaded runs.
>>>>  After
>>>> running debugging utilities it appears that there are some static
>>>> variables
>>>> in the avl_map.cpp file that I can't find proper locks for anywhere.  Am
>>>> I
>>>> missing something?
>>>>
>>>> Thank you for your help,
>>>> Megan
>>>> _______________________________________________
>>>> AGENTPP mailing list
>>>> AGENTPP at agentpp.org
>>>> http://lists.agentpp.org/mailman/listinfo/agentpp
>>>>
>>>> --
>>> AGENT++
>>> http://www.agentpp.com
>>> http://www.mibexplorer.com
>>> http://www.mibdesigner.com
>>>
>>> _______________________________________________
>> AGENTPP mailing list
>> AGENTPP at agentpp.org
>> http://lists.agentpp.org/mailman/listinfo/agentpp
>>
>
> --
> AGENT++
> http://www.agentpp.com
> http://www.mibexplorer.com
> http://www.mibdesigner.com
>