[bind10-dev] proposed design of scalable in-memory zone loading/updating

[JINMEI Tatuya / 神明達哉]

At Fri, 22 Jun 2012 15:53:31 -0700,
Jerry Scharf <scharf at isc.org> wrote:

> I didn't see anything in this describing the locking needed to make sure 
> that subtrees are in a consistent state when accessing the shared 
> memory. This seems like an important part of understanding the proposal.

(You're right that this design memo doesn't talk about inter-process
contention with the shared-memory based architecture).

My understanding is that, when we support the shared-memory based
memory management, we'll use two copies of the same data, one for
read-only, and the other for updates.  Initially, the memory
management process ("memmgr") prepares the two copies from some source
(either by loading from a file or other DB to shared-memory segments
or by mmap'ing the memory image file two times), and lets auth server
instances get access to one of the copies (read-only).  When some
event (like xfr-in) requires updates to the data, memmgr updates the
other part of the copy.  When memmgr completes the update task, it
tells the auth server instances that they need to switch to a new
segment (which now becomes the "read-only" copy).  When all instances
switch to the new segment, memmgr makes the update to the other copy
(which now becomes updatable segment).  These processes repeat this
cycle.

So, there should be no contention (synchronization happens only when
memmgr switches one copy to another), and there should be no need for
explicit locking on data.  Of course it trades memory for the speed
(and simplicity).

---
JINMEI, Tatuya