Comments on Replacing C

[Achim Gratz]

Hal Murray writes:
> How well do the languages/systems you are considering support threading?

Concurrency doesn't have to be supported via threads at the language
level, although they'd map to something thread-like in the kernel most
likely.

> What should our code look like in the long term?  Will crypto chew up a lot 
> of cycles?  Could a busy server support more clients by running several 
> threads in parallel on multiple CPUs?

Certainly.  That's one of the poster child applications for threading
(assuming we never saturate the network link).

> Is there any reason not to use multiple threads?

Contention over shared state and possibility of deadlock.  For the
application above it should be possible to guarantee deadlock-free
implementation easily.  But NTP has a large global state, so it will
likely spend time while serialized while that state gets changed.

> Would we actually gain anything from multiple threads?  Would they all merge 
> back together queuing up for the crypto hardware?

The crypto hardware that NTP is going to encounter most commonly is
instruction set extensions at the CPU level I'd think, so each CPU
thread has its own resource.  Things might be different if we'd use an
offload engine in the NIC, but that would be sized to work at wire
speed, which NTP is unlikely to max out.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs