BIND 10 #2874: Test the Coroutines/RCU approach for resolver multi-threading
BIND 10 Development
do-not-reply at isc.org
Mon Mar 18 07:57:51 UTC 2013
#2874: Test the Coroutines/RCU approach for resolver multi-threading
----------------------------------------+----------------------------------
Reporter: vorner | Owner:
Type: task | Status: new
Priority: medium | Milestone: New Tasks
Component: resolver | Keywords:
CVSS Scoring: | Sensitive: 0
Defect Severity: N/A | Sub-Project: DNS
Feature Depending on Ticket: | Estimated Difficulty: 0
Add Hours to Ticket: 0 | Total Hours: 0
Internal?: 0 |
----------------------------------------+----------------------------------
On top of #2871 implement the coroutines/RCU approach and measure its
performance.
Each query is a separate coroutine with its own stack, multiple coroutines
live in a single thread (and they don't move from one thread to another).
If a query waits for something external (eg. network IO), it yields and
other coroutine can be run (if there's any other waiting). As many things
that can be are thread-private, so they don't have to be locked (we can,
for example, have own copy of the network sockets, logging, L1 cache).
Things that need to be locked are locked by mutexes the usual way. The
only exception is the cache, that would be done by RCU. Read accesses are
without locking, only the updates need lock. Test whether we need multiple
locks for parts of the cache or one is enough.
Also, check if we need to „recycle“ used coroutines.
It was suggested to try out the boost.Coroutine library for the
experiment, as we already use boost.
More detail can be found in
https://lists.isc.org/pipermail/bind10-dev/2013-March/004493.html.
--
Ticket URL: <http://bind10.isc.org/ticket/2874>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list