[bind10-dev] Multicore Auth

[JINMEI Tatuya / 神明達哉]

At Fri, 15 Jul 2011 10:25:13 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > - One key question is how often we want to be able to reflect changes.
> >   If we want to support, say, 1000 dynamic updates / sec and want to
> >   make the changes visible "instantly", I can hardly imagine any other
> >   approach than multi threads + locking (there may be a clever way to
> >   achieve the goal with, e.g., shared memory + multiple processes,
> >   still involving very few synchronization overhead, but I have no
> >   specific idea right now).  If we can allow some delay in propagating
> >   changes so that we can apply a set of changes at once and
> >   periodically (e.g., every 30sec), other approaches such as multi
> >   process + shared memory image can be a solution.  Do we have any
> >   specific goal/requirement regarding this question?
> 
> Well, as far as I looked, it is possible to have not only shared memory, but
> shared mutexes and locks. That way we can have separate processes and still
> propagate pretty fast by locking in some kind of shared memory.
> 
> Also, as Evan noted, if we have a big mostly stable area and small „journal“,
> this can propagate changes fast as well.

I'm not that optimistic, once the design involves heavy use of
synchronization primitives.  The nightmare with heavy use of threads
won't magically disappear simply because we use something that has a
different name than threads but is equally evil.  In that sense, I
believe my concern still stands: I can hardly imagine any other
approach than multi threads + locking.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.