[quagga-dev 12077] Re: Advise on implementation

David Lamparter equinox at opensourcerouting.org
Mon Mar 2 20:53:48 GMT 2015


On Mon, Mar 02, 2015 at 04:28:29PM +0100, Olivier Dugeon wrote:
> Hum, it depends if we follow Posix or SysV. In both case, if the
> system is compliant with POSIX or SysV, the portability is normally
> guarantee. But, we need to test to verify.  Now, there is a difference
> between POSIX and SysV regarding the semaphore needed to protect the
> Shared Memory space. In SysV, when a process crash, the system will
> release the semaphore if SEM_UNDO flag has been set. This guarantee
> that the system will not block even if a process crash once acquired
> the lock. In POSIX, there is not similar feature.  So, in POSIX, you
> must add your own supervision/monitoring system to keep the whole
> system safe even in case of crash.

There's another question here.  Are we talking about a request-response
or a publish protocol?  Both shm and sockets can implement either.

For a publish protocol over SHM, any kind of locking would need to be on
an object level, not over the entire SHM area.  Also, it still needs
update event signaling to make responses to updates event driven.

This means, even if all state is in SHM, either there is an additional
SHM event signaling mechanism (like a journal), or it ends up SHM+socket
in parallel.

Yet another question is, who will write to what particular SHM areas.
It can be one big SHM for everything, or one SHM is only written by one
daemon, or there are SHM areas for each object, or ...

Ultimately, SHM has two big dangers:
- becoming a single non-queued point of contention (locking too broadly)
- weakening crash isolation between protocol daemons


-David

> Le 02/03/2015 14:50, Michael H Lambert a écrit :
> > On 2 Mar 2015, at 02:18, David Lamparter <equinox at opensourcerouting.org> wrote:
> >> NB: I'm not against SHM, but I do think SHM is more difficult to get
> >> right, and it's not an automatic performance win.  I did some thinking
> >> about a shared memory RCU-based replacement for ZAPI, but never had the
> >> time to try that.  It probably *does* help moving Quagga towards
> >> supporting multiple threads in the individual daemons.
> > How difficult is it to do SHM portably?  That could be the decider.
> >
> > Michael
> >
> >
> > _______________________________________________
> > Quagga-dev mailing list
> > Quagga-dev at lists.quagga.net
> > https://lists.quagga.net/mailman/listinfo/quagga-dev
> >
> >
> 
> 
> 
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev at lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-dev




More information about the Quagga-dev mailing list