Re: Semaphore / Synchronizing write operations

The agent/mibgroup/mibII/setSerialNo.c dont use the

netsnmp_register_watched_spinlock( netsnmp_handler_registration
*reginfo,int *spinlock) function!

Is the setSerialNo.c way to implemente the spinlock deprecated?
Or is only a diferent way to do the same thing ?

For a simple scenario, whats the best aproach?

Thanks once again.



----- Original Message -----
From: "Dave Shield" <D.T.Shield@liverpool.ac.uk>
To: "vsaavedra" <vsaavedra@maisis.pt>
Cc: <net-snmp-users@lists.sourceforge.net>
Sent: Tuesday, October 23, 2007 10:48 AM
Subject: Re: Semaphore / Synchronizing write operations


> On 23/10/2007, vsaavedra <vsaavedra@maisis.pt> wrote:
> > Is there any example where I can look?
>
> agent/mibgroup/mibII/setSerialNo.c
>
>
>
>
> > To retrive table values I do :
> > snmpbulkwalk -v2c -Os -c public localhost applicationTypeTable
> >
> > How can I change this command to retrive the spinlock value?
>
> snmpbulkwalk -v2c -Os -c public -Cn1 localhost spinLockObject
> applicationTypeTable
>
> Dave
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Net-snmp-users mailing list
> Net-snmp-users@lists.sourceforge.net
> Please see the following page to unsubscribe or change other options:
> https://lists.sourceforge.net/lists/...net-snmp-users
>

On 16/10/2007, vsaavedra <vsaavedra@maisis.pt> wrote:
> My problem is: When two applications try to update de MIB at same time,
it's
> possible that one application rewrite the data that other application just
> wrote.
>
> How can I guarantee that two applications can't update the same node at
the
> same time.

The usual SNMP mechanism for implementing this would be a MIB 'TestAndIncr'
object. Each application would retrieve the contents of the table
together with
this semaphore value (as a single SNMP request). They would then issue a
SET request, containing the new table values and this same semaphore value
(again, as a single SNMP request).

The first client would be providing the same semaphore value as the one
read,
so the SET request would succeed (incrementing the internal semaphore
value).
The second client would now be providing an out-of-date semaphore value,
so the SET request would be rejected.

There is a helper routine
int netsnmp_register_watched_spinlock(
netsnmp_handler_registration *reginfo,
int *spinlock);

to implement just such a semaphore object.

Dave

[This response has been saved as a Good Answer on the project wiki pages
http://www.net-snmp.org/wiki/index.p...icting_updates
]


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/...net-snmp-users