[bind10-dev] Multicore Auth

Michal 'vorner' Vaner michal.vaner at nic.cz
Wed Jul 13 12:09:26 UTC 2011


Hello

On Wed, Jul 13, 2011 at 11:33:03AM +0100, Stephen Morris wrote:
> A variant of this would be to use two copies of the data:
> 
> Programs map to one copy and answer queries from it.  There is no
> locking as all access is read-only.

There's still some kind of synchronization to do the switch or something. Maybe
it's not exactly locking, but something can't be avoided I guess. But yes,
having to do it only at the switch looks nice.

> There are pitfalls with C++ allocators, e.g. STL assumes that allocators
> for a particular type are equivalent.  So if we (using the example given
> in Meyers's book "Effective STL") splice elements from list L1 (which
> uses allocator A) into L2 (which uses allocator B), when L2 is destroyed
> the elements of L1 will destroyed using L2's allocator.

I'd rather like to avoid C++ allocation there completely. If we build the tree
(or whatever it is) and use the thing from #404, we can be safe with few large
arrays. It helps with the shared memory to know where data live and we can place
it in a way we can control how well it will be cached in the CPU cache.

With regards

-- 
No, I will not change your lightbulb.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20110713/b082f52e/attachment.bin>


More information about the bind10-dev mailing list