Date: Fri, 29 Mar 2024 15:06:21 +0000 (UTC) Message-ID: <1506954070.177.1711724781643@2997b7dde346> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_176_1591634975.1711724781642" ------=_Part_176_1591634975.1711724781642 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
By default AGENT++ is a multi-threaded agent. Therefore access to each M= ibEntry in the a Mib has to be synchronized.
In order to reduce blocking of concurrent requests, AGENT++ uses a two l= evel lockin:
As tables and complex (sub-tree) entries may contain also MibEntry objec= ts, for example scalars, additional levels can be implemented by the user.<= /p>
In any case, the locking procedure boundary must be implemented acc= ording to the following schema:
Mib* mi= b; ... mib->lock_mib(); // code to lookup a MibEntry (replace "my context" with "" or your context = and the OID by the table entry OID, for example): MibTable* table =3D (MibTable*) mib->get("my context", "1.3.6.1.4.1.????= .1"); // enter protected region: table->start_synch(); // now you can drop the Mib lock mib->unlock_mib(); // do the real work on table ... table->end_synch();
If you need to add/remove objects from the Mib, the locking schema looks= sligtly different:
Mib* mi= b; ... mib->lock_mib(); // code to lookup a MibEntry: MibTable table =3D ...; // enter protected region: table->start_synch(); // remove table from Mib: MibContext* ctx =3D mib->get_context(DEFAULT_CONTEXT); ctx->remove(*table->key()); table->end_synch(); delete table; // now you can drop the Mib lock mib->unlock_mib();