[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