\usepackage{amsmath}
\usepackage{courier}
\usepackage{graphicx}
+\usepackage[ruled,lined]{algorithm2e}
\newcommand{\abs}[1]{\lvert#1\rvert} % \abs{x} -> |x|
+\newenvironment{algodata}{%
+ \begin{tabular}[t]{@{}l@{:~}l@{}}}{%
+ \end{tabular}}
+
+\newcommand{\VAR}[1]{\textit{#1}}
+
\begin{document}
\title{Best effort strategy and virtual load
of messages: load information messages and load balancing messages. More
precisely, a node wanting to send a part of its load to one of its neighbors,
can first send a load information message containing the load it will send and
-then it can send the load balancing message containing data to be transfered.
+then it can send the load balancing message containing data to be transferred.
Load information message are really short, consequently they will be received
very quickly. In opposition, load balancing messages are often bigger and thus
-require more time to be transfered.
+require more time to be transferred.
The concept of \texttt{virtual load} allows a node that received a load
information message to integrate the load that it will receive later in its load
\paragraph{Receiving thread} The receiving thread is in charge of
waiting for messages to come, either on the control channel, or on the
-data channel. When a message is received, it is pushed in a buffer of
+data channel. Its behavior is sketched by Algorithm~\ref{algo.recv}.
+When a message is received, it is pushed in a buffer of
received message, to be later consumed by one of the other threads.
There are two such buffers, one for the control messages, and one for
the data messages. The buffers are implemented with a lock-free FIFO
\cite{sutter.2008.writing} to avoid contention between the threads.
+\begin{algorithm}
+ \caption{Receiving thread}
+ \label{algo.recv}
+ \KwData{
+ \begin{algodata}
+ \VAR{ctrl\_chan}, \VAR{data\_chan}
+ & communication channels (control and data) \\
+ \VAR{ctrl\_fifo}, \VAR{data\_fifo}
+ & buffers of received messages (control and data) \\
+ \end{algodata}}
+ \While{true}{%
+ wait for a message to be available on either \VAR{ctrl\_chan},
+ or \VAR{data\_chan}\;
+ \If{a message is available on \VAR{ctrl\_chan}}{%
+ get the message from \VAR{ctrl\_chan}, and push it into \VAR{ctrl\_fifo}\;
+ }
+ \If{a message is available on \VAR{data\_chan}}{%
+ get the message from \VAR{data\_chan}, and push it into \VAR{data\_fifo}\;
+ }
+ }
+\end{algorithm}
+
\paragraph{Computing thread} The computing thread is in charge of the
-real load management. It iteratively runs the following operations:
+real load management. As exposed in Algorithm~\ref{algo.comp}, it
+iteratively runs the following operations:
\begin{itemize}
\item if some load was received from the neighbors, get it;
\item if there is some load to send to the neighbors, send it;
\end{itemize}
Practically, after the computation, the computing thread waits for a
small amount of time if the iterations are looping too fast (for
-example, when the current load is zero).
+example, when the current load is near zero).
+
+\begin{algorithm}
+ \caption{Computing thread}
+ \label{algo.comp}
+ \KwData{
+ \begin{algodata}
+ \VAR{data\_fifo} & buffer of received data messages \\
+ \VAR{real\_load} & current load \\
+ \end{algodata}}
+ \While{true}{%
+ \If{\VAR{data\_fifo} is empty and $\VAR{real\_load} = 0$}{%
+ wait until a message is pushed into \VAR{data\_fifo}\;
+ }
+ \While{\VAR{data\_fifo} is not empty}{%
+ pop a message from \VAR{data\_fifo}\;
+ get the load embedded in the message, and add it to \VAR{real\_load}\;
+ }
+ \ForEach{neighbor $n$}{%
+ \If{there is some amount of load $a$ to send to $n$}{%
+ send $a$ units of load to $n$, and subtract it from \VAR{real\_load}\;
+ }
+ }
+ \If{$\VAR{real\_load} > 0.0$}{
+ simulate some computation, whose duration is function of \VAR{real\_load}\;
+ ensure that the main loop does not iterate too fast\;
+ }
+ }
+\end{algorithm}
\paragraph{Load-balancing thread} The load-balancing thread is in
charge of running the load-balancing algorithm, and exchange the
iterate too fast.
\end{itemize}
+\begin{algorithm}
+ \caption{Load-balancing}
+ \label{algo.lb}
+ \While{true}{%
+ \While{\VAR{ctrl\_fifo} is not empty}{%
+ pop a message from \VAR{ctrl\_fifo}\;
+ identify the sender of the message,
+ and update the current knowledge of its load\;
+ }
+ run the load-balancing algorithm to make the decision about load transfers\;
+ \ForEach{neighbor $n$}{%
+ send a control messages to $n$\;
+ }
+ ensure that the main loop does not iterate too fast\;
+ }
+\end{algorithm}
+
+\paragraph{}
+For the sake of simplicity, a few details were voluntary omitted from
+these descriptions. For an exhaustive presentation, we refer to the
+actual code that was used for the experiments, and which is
+available at \textbf{FIXME URL}.
+
+\textbf{FIXME: ajouter des détails sur la gestion de la charge virtuelle ?}
+
\subsection{Experimental contexts}
\label{Contexts}
-\textbf{FIXME once the experimentations are done!}
+\textbf{FIXME once the experimentation is done!}
\begin{description}
\item[platforms] homogeneous ; heterogeneous generated with the SIMULACRUM tool~\cite{QUINSON:2010:INRIA-00502839:1}
\item[topologies]
% LocalWords: Raphaël Couturier Arnaud Giersch Abderrahmane Sider Franche ij
% LocalWords: Bertsekas Tsitsiklis SimGrid DASUD Comté Béjaïa asynchronism ji
-% LocalWords: ik isend irecv
+% LocalWords: ik isend irecv Cortés et al chan ctrl fifo
