Here are a few words from Orion last year about implementing parallelism
in XORP XRL targets.
Consider carefully that the process code itself must be thread safe,
before we consider libxipc thread safety.
--- Begin Message ---
> I'm actually for multi-threading. You'll need to go there at some point
> to use all the horse power of modern machines. (I realize that it's
> difficult to code right, but that's the price unfortunately.)
>
Process level parallelism goes a fair way, and converting the existing
code base would be difficult and time consuming. If XORP inc goes well a
complete re-write will become a possibility as resources become available,
but going with what there is now is probably the most prudent.
Mark's suggestion of XRLs is good for the send side of XRLs and
straightforward to encapsulate (?). Callbacks need to be dispatched on the
invoking thread because otherwise bad things will happen if the code is
not completely thread-safe.
Going beyond this is probably fairly hard given the amount of code and the
extensive use of the STL. I don't know what the state of art thread-safe
data structures are in the C++ world, but the STL was deliberately not
thread safe (C++0X is supposed to add better concurrency support into the
language).
If people have thoughts on options, they'd be good to share. Options that
spring to mind:
1) multi-colored callbacks a la Zeldovich et al
(http://www.scs.stanford.edu/~dm/home/papers/zeldovich:async-mp.pdf). I
believe this is fine for web servers, but fairly hard to retrofit to XORP
and guarantee correctness, and I don't believe it scales up for anyone
without a PhD from MIT working on their best day.
2) stage-server/SEDA
(http://www.usenix.org/event/usenix02/full_papers/larus/larus_html/index.html)
:- this has potentially good cache performance if threads are affinitized
to different cores, but requires reworking process architectures.
3) have a watershed whereby new code is multithreaded and old code isn't.
Consider in that watershed making a thread friendly language first tier
supported.
4) do nothing. Threads obviously have diminishing returns if the number of
threads exceeds the number of cores. Worlds about to hit 8 cores (or at
least 8 threads) on the commodity PC, a core per xorp process and a couple
to share :-).
_______________________________________________
Xorp-dev mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-dev
--- End Message ---
_______________________________________________
Xorp-hackers mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
