[bind10-dev] Threads and resolvers, was more about cache (Re: cache effectiveness)

[Shane Kerr]

Michal,

On Thursday, 2013-02-28 09:05:22 +0100, 
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:
> Hello
> 
> I noticed you kind of implicitly assume threads. I guess nothing
> would change too much in this stage of design if we consider separate
> processes, but we should probably answer that question. In my
> understanding, we wanted to avoid threads if at all possible.

Just for clarity, in any type of multi-processor support we want to
avoid access contention whenever possible (basically lock contention,
but there may be other issues like CPU-cache sizes and so on).

That is independent of whether we use threads or processes.

The main issue with using threads is that we end up with fate sharing,
so that if we have a coding bug we lose all state on a process and have
to re-start ALL recursive resolution.

A multi-process model can easily eliminate fate sharing due to
most coding bugs. However, a multi-process model that maintains
separate caches will be less efficient. But sharing a cache introduces
a point of shared state - one process corrupting a cache is just as bad
(or worse!) as a single thread corrupting the cache in a threaded model.

While we cannot eliminate the possibility of a corrupted cache if there
is a shared cache, we can perhaps limit the risk with careful
encapsulation of caching operations. Probably this is a reasonable idea
even in a multi-threaded model, although there may be a performance hit.

Cheers,

--
Shane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130228/70fe1f3e/attachment.bin>