Hello David,
Le 02/03/2015 21:53, David Lamparter a écrit :
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.
I think we need both. In some case we just need to publish information
e.g. when Zebra push new information about interface to all process, and
sometimes request-response when ask for entire LSA Database for example.
Another kind of communication is to subscribe to some events like OSPF-API
allow to be in touch with new LSA advertisement.
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 is the tricky point.I'm looking for a bus behaviour (like on ACTA
or VME)
where there is a writer locking the bus and 'n' readers with an addressing
mechanism to let readers determine if the information is for their or
not.Bus
is release once the complete write/read cycle is finish. Of course, we
could imagine
a ring buffer to increase the bus capacity, locking only some part of
the bus, or
adding many bus, for different purpose.
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.
I would keep as much as possible state and data in SHM, but I agree that we
need an event signalling mechanism. I'm looking to semaphore jointly
with SHM
(semaphore will be store in the SHM in order to be shared between all
process)
to i) protect the SHM ii) signal when new message is available in the SHM.
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 ...
Both options are feasible. One Bus/SHM with all process able to act as a
writer
or reader with appropriate locking mechanism (it is why I'm trying to
implement)
or a dedicated Bus/SHM per process. Once I finish implement the first
one, I think
it could be replicate to support the second.
Ultimately, SHM has two big dangers:
- becoming a single non-queued point of contention (locking too broadly)
- weakening crash isolation between protocol daemons
Yes for sure. For that purpose, I look to 2 solutions. First, use SysV
semaphore
that let the Kernel supervise the semaphore if one of the daemon crash.
The semaphore
is release even if the process that own the semaphore has not release it
before crashing.
The second option, if SysV is too old/deprecated regarding POSIX, is to
implement a
gatekeeper that regularly look to the semaphore and release it if there
is something
wrong. In Quagga, Zebra is the basis daemon. If it crashes, all other
daemon could not
run properly. So, I'm thinking about a small thread under Zebra daemon
that supervise
the semaphore and SHM.
Regards,
Olivier
-David
Le 02/03/2015 14:50, Michael H Lambert a écrit :
On 2 Mar 2015, at 02:18, David Lamparter <[email protected]> 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
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
