Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Search typedefs of pointer to function where they now live
[simgrid.git] / doc / module-gras.doc
index 061a957..5c3d672 100644 (file)
     
        - \ref GRAS_ex_ping
        - \ref GRAS_ex_mmrpc
+       - \ref GRAS_ex_token
        - \ref GRAS_ex_timer
 
-    @{ */
+    @{ */
        /** @defgroup GRAS_comm    Communication facilities */
        /** @defgroup GRAS_run     Virtualization */
        /** @defgroup GRAS_code    Project and code management */
@@ -83,6 +84,8 @@
 #####################################################################
 /** @addtogroup GRAS_run
 
+   Virtualization facilities allow your code to run both on top of the simulator or in real setting.
+
     @{ */     
         
        /** @defgroup GRAS_globals Globals               */ 
 #####################################################################
 /** @addtogroup GRAS_code
 
+    Here is how to setup your code when you want to use GRAS. You will also
+    learn how to get the most repetitive parts of your code generated
+    automatically.
+
+    (use the tabs on top of the page to navigate)
+
     \htmlonly <!-- 
       DOXYGEN_NAVBAR_LABEL="Project management"
       DOXYGEN_NAVBAR_CHILD "main() and GRAS"=GRAS_main_generation.html
 #####################################################################
 /** @addtogroup GRAS_ex
 
+    There is for now rather few examples of GRAS, but it's better than
+    nothing, isn't it?
+
+       - \ref GRAS_ex_ping
+       - \ref GRAS_ex_mmrpc
+       - \ref GRAS_ex_token
+       - \ref GRAS_ex_timer
+
     \htmlonly <!-- 
       DOXYGEN_NAVBAR_CHILD "Ping-Pong"=GRAS_ex_ping.html
       DOXYGEN_NAVBAR_CHILD "RPC"=GRAS_ex_mmrpc.html
+      DOXYGEN_NAVBAR_CHILD "Token Ring"=GRAS_ex_token.html
       DOXYGEN_NAVBAR_CHILD "Timers"=GRAS_ex_timer.html
     --> \endhtmlonly
+
+  There is some more examples in the distribution, under the directory
+  <tt>examples/gras</tt>.
 */
 
 #####################################################################
        
     <hr>
 
-    \dontinclude gras/ping/ping.c
+    \dontinclude gras/ping/ping_common.c
     
     \section GRAS_ex_ping_common 1) Common code to the client and the server 
     
     \subsection GRAS_ex_ping_initial 1.a) Initial settings
     
-    Let's first load the gras header and declare a logging category (see
+    Let's first load the module header and declare a logging category (see
     \ref XBT_log for more info on logging).
     
     \skip include
     \until XBT_LOG
+    
+    The module header <tt>ping.h</tt> reads:
+    
+    \dontinclude gras/ping/ping.h
+    \skip include
+    \until argv
+    \until argv
 
     \subsection GRAS_ex_ping_register 1.b) Register the messages
     
     involve any newly created types but only int, this is quite easy. 
     (to exchange more complicated types, see \ref GRAS_dd or 
     \ref GRAS_ex_mmrpc for an example).
-    
+
+    \dontinclude gras/ping/ping_common.c
     \skip register_messages
     \until }
 
     struct definition so that they can be handled properly in GRAS (see the
     \ref GRAS_globals for more info).
 
+    \dontinclude gras/ping/ping_server.c
     \skip typedef struct
     \until }
     
     This function is quite straightforward, and the inlined comments should
     be enough to understand it.
 
+    \dontinclude gras/ping/ping_client.c
     \skip client
     \until end_of_client
 
     [Back to \ref GRAS_ex_ping_toc]
  */
 
+---------------------------------------------------------------------
+--------------------- Simple Token Ring -----------------------------
+---------------------------------------------------------------------
+
+/** \page GRAS_ex_token Token Ring example
+
+   This example implements the token ring algorithm. It involves several
+   nodes arranged in a ring (each of them have a left and a right neighbour)
+   and exchanging a "token". This algorithm is one of the solution to ensure
+   the mutual exclusion between distributed processes. There is only one
+   token at any time, so the process in its possession is ensured to be the
+   only one having it. So, if there is an action you want all processes to
+   do alternativly, but you cannot afford to have two processes doing it at
+   the same time, let the process having the token doing it.
+   
+   Actually, there is a lot of different token ring algorithms in the
+   litterature, so this example implements one of them: the simplest one.
+   The ring is static (no new node can join it, and you'll get trouble if
+   one node dies or leaves), and nothing is done for the case in which the
+   token is lost. 
+
+   - \ref GRAS_ex_stoken_deploy
+   - \ref GRAS_ex_stoken_global
+   - \ref GRAS_ex_stoken_callback
+   - \ref GRAS_ex_stoken_main
+
+   \section GRAS_ex_stoken_deploy 1) Deployment file
+
+   Here is the deployment file:
+   \include examples/gras/tokenS/tokenS_deployment.xml
+   
+   The neighbour of each node is given at startup as command line argument.
+   Moreover, one of the nodes is instructed by a specific argument (the one
+   on Tremblay here) to create the token at the begining of the algorithm.
+   
+   \section GRAS_ex_stoken_global 2) Global definition
+   
+   The token is incarned by a specific message, which circulates from node
+   to node (the payload is an integer incremented at each hop). So, the most
+   important part of the code is the message callback, which forwards the
+   message to the next node. That is why we have to store all variable in a
+   global, as explained in the \ref GRAS_globals section. 
+
+   \dontinclude examples/gras/tokenS/tokenS.c
+   \skip typedef
+   \until }
+   
+   \section GRAS_ex_stoken_callback 3) The callback
+   
+   Even if this is the core of this algorithm, this function is quite
+   straightforward.
+   
+   \skip node_cb_stoken_handler
+   \until end_of_node_cb_stoken_handler
+
+   \section GRAS_ex_stoken_main 4) The main function
+   
+   This function is splited in two parts: The first one performs all the
+   needed initialisations (points 1-7) while the end (point 8. below) calls 
+   gras_msg_handle() as long as the planned amount of ring loops are not
+   performed.
+   
+   \skip node
+   \until end_of_node
+
+*/
+
 ---------------------------------------------------------------------
 -------------------------- MM RPC -----------------------------------
 ---------------------------------------------------------------------
 
     \section GRAS_ex_mmrpc_toc Table of contents of the mmrpc example
       - \ref GRAS_ex_mmrpc_common
-        - \ref GRAS_ex_mmrpc_initial
+        - \ref GRAS_ex_mmrpc_header
         - \ref GRAS_ex_mmrpc_dataregister
+        - \ref GRAS_ex_mmrpc_logdef
         - \ref GRAS_ex_mmrpc_msgregister
+        - \ref GRAS_ex_mmrpc_matdump
       - \ref GRAS_ex_mmrpc_server
+       - \ref GRAS_ex_mmrpc_serinc
        - \ref GRAS_ex_mmrpc_sercb
        - \ref GRAS_ex_mmrpc_sermain
       - \ref GRAS_ex_mmrpc_client
+       - \ref GRAS_ex_mmrpc_cliinc
        - \ref GRAS_ex_mmrpc_climain
        
     <hr>
 
-    \dontinclude gras/mmrpc/mmrpc.c
     
-    \section GRAS_ex_mmrpc_common 1) Common code to the client and the server 
+    \section GRAS_ex_mmrpc_common 1) Common code to the client and the server (mmrpc_common.c and mmrpc.h)
     
-    \subsection GRAS_ex_mmrpc_initial 1.a) Initial settings
-    
-    Let's first load the gras header, specify the matrix size and declare a 
-    logging category (see \ref XBT_log for more info on logging).
     
+    \subsection GRAS_ex_mmrpc_header 1.a) Module header (mmrpc.h)
+
+    This loads the gras header and declare the function's prototypes as well
+    as the matrix size.
+
+    \dontinclude gras/mmrpc/mmrpc.h
     \skip include
-    \until XBT_LOG
+    \until argv
+    \until argv
 
-    \subsection GRAS_ex_mmrpc_dataregister 1.b) Register the data types
+    \subsection GRAS_ex_mmrpc_dataregister 1.b) Register the data types (mmrpc.h)
 
     The messages involved in this example do use structures as payload, 
     so we have to declare it to GRAS. Hopefully, this can be done easily by enclosing 
     \skip GRAS_DEFINE_TYPE
     \until matrix_t
 
-    \subsection GRAS_ex_mmrpc_msgregister 1.c) Register the messages
+    \subsection GRAS_ex_mmrpc_logdef 1.c) Logging category definition (mmrpc_common.c)
+    
+    Let's first load the module header and declare a logging category (see
+    \ref XBT_log for more info on logging). This logging category does live
+    in this file (ie the required symbols are defined here and declared as
+    "extern" in any other file using them). That is why we use 
+    \ref XBT_LOG_NEW_DEFAULT_CATEGORY here and 
+    \ref XBT_LOG_EXTERNAL_DEFAULT_CATEGORY in mmrpc_client.c and mmrpc_server.c.
+    
+    \dontinclude gras/mmrpc/mmrpc_common.c
+    \skip include
+    \until XBT_LOG
+
+    \subsection GRAS_ex_mmrpc_msgregister 1.d) Register the messages (mmrpc_common.c)
     
     This function, called by both the client and the server is in charge of
     declaring the existing messages to GRAS. Note the use of the \ref gras_datadesc_by_symbol 
     \skip register_messages
     \until }
 
+    \subsection GRAS_ex_mmrpc_matdump 1.e) Helper debugging function (mmrpc_common.c)
+
+    This function dumps a matrix to screen for debugging.
+    
+    \skip mat_dump
+    \until end_of_matrix
+    \until }
+
     [Back to \ref GRAS_ex_mmrpc_toc]
 
-    \section GRAS_ex_mmrpc_server 2) Server's code
+    \section GRAS_ex_mmrpc_server 2) Server's code (mmrpc_server.c)
+    
+    \subsection GRAS_ex_mmrpc_serinc 2.a) Server intial settings
     
-    \subsection GRAS_ex_mmrpc_sercb 2.a) The callback to the mmrpc message
+    All module symbols live in the mmrpc_common.c file. We thus have to
+    define \ref GRAS_DEFINE_TYPE_EXTERN to the preprocessor so that the
+    \ref GRAS_DEFINE_TYPE symbols don't get included here. Likewise, we use 
+    \ref XBT_LOG_EXTERNAL_DEFAULT_CATEGORY to get the log category in here.
+    
+    \dontinclude gras/mmrpc/mmrpc_server.c
+    \skip define
+    \until XBT_LOG
+
+    \subsection GRAS_ex_mmrpc_sercb 2.b) The callback to the mmrpc message
 
     Here is the callback run when the server receives any mmrpc message (this
     will be registered later by the server). Note the way we get the message 
     \skip server_cb_request_handler
     \until end_of_server_cb_request_handler
 
-    \subsection GRAS_ex_mmrpc_sermain 2.b) The "main" of the server
+    \subsection GRAS_ex_mmrpc_sermain 2.c) The "main" of the server
     
     This is the "main" of the server. As explained in the \ref
     GRAS_main_generation, you must not write any main()
     
     [Back to \ref GRAS_ex_mmrpc_toc]
 
-    \section GRAS_ex_mmrpc_client 3) Client's code
+    \section GRAS_ex_mmrpc_client 3) Client's code (mmrpc_client.c)
     
-    \subsection GRAS_ex_mmrpc_climain 3.a) Client's "main" function
+    \subsection GRAS_ex_mmrpc_cliinc 2.a) Server intial settings
+    
+    As for the server, some extra love is needed to make sure that automatic
+    datatype parsing and log categories do work even if we are using several
+    files.  
+    
+    \dontinclude gras/mmrpc/mmrpc_client.c
+    \skip define
+    \until XBT_LOG
+
+    \subsection GRAS_ex_mmrpc_climain 3.b) Client's "main" function
     
     This function is quite straightforward, and the inlined comments should
     be enough to understand it.
 
-    \skip client
+    \dontinclude gras/mmrpc/mmrpc_client.c
+    \skip argv
     \until end_of_client
 
     [Back to \ref GRAS_ex_mmrpc_toc]