[bind10-dev] Non-preemptive threads as an alternative to events?

[Michal 'vorner' Vaner]

Hello

On Mon, Mar 14, 2011 at 01:11:30PM +0100, Shane Kerr wrote:
> The idea here is that you only switch context during well-defined points
> in the program - specifically the functions provided by the thread
> library. In principle, this means you get the advantages of
> multithreaded code (easy to read), with few of the disadvantages. The
> drawback is that you can only use a single CPU at a time, since you are
> only ever executing a single thread at a time. But that works okay for
> servers that mostly spend their lives waiting on network I/O.

I agree that the asynchronous/event loop approach is kind of tiresome in C++
(though less with objects than without them) than in languages where we have
closures ‒ closures kind of help maintaining the state and look as part of the
code, even when indented a little ‒ so they act a lot like a block inside the
function, syntactically.

Speaking about what is easier, in auth it doesn't matter much. We have a place
that handles the IO, and it doesn't matter much if there's a poll or blocking
call or whatever is there. It's small amount of code. And the rest of processing
is not waiting for anything, it just constructs the answer in quite usual way.

The thing with resolver is different and I'm not sure what is more convenient
there, if events or threads. But considering the part I worked on ‒ the NSAS,
where there could be multiple request for the same information, so the callbacks
are put together and called all at once when the information arrives would be
hell to do by thread synchronisation (or, maybe not, but I have no idea how to
do that). I admit that it's not simple with events either. Maybe something like
condition and wake all threads waiting on the information could do the trick.

Anyway, cooperative threads (or, coroutines) have the problem, as you mentioned,
that you can't do more than one in parallel. Or, you can, but you're in the
full-thread world then.

And, the situation is:
 • The speed of processors isn't growing that much lately.
 • The number of cores/processors inside a machine is growing quite a lot (I
   heard a rumor that Intel showed some 256-core CPU/GPU hybrid that could
   actually use all the 256 cores to do computations).
 • Network speeds are growing.
 • Sizes of zones are growing.

So, if we're planning for next 10+ years, it seems to me there's a need to use
multiple CPUs in parallel. If it's with threads or events, I don't know. But we
probably will have to do some locking. If we are careful, we might be able to do
it in a way there's only little locking (there aren't that many places to
interact, only the data source, all caches, NSAS, possibly a task queue, if we
split the application to IO threads and work threads).

I personally think that the best way to do it would be kind of hybrid. Many
things are better modeled by threads (going trough conditions, handling error
states, etc). But as noted, there might be places where it just doesn't do well.

And, if we use threads, having as many real threads as concurrent queries in
resolver is probably a no way to go, so in the optimal case we could have
userland threads (the coroutines) and have them executed on few OS-level threads
(like the same amount as we have processors, or twice as much to do something
while there's some locking).

Yes, I agree this needs to be looked into.

Have a nice day

-- 
Support your right to arm bears!!

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