1 /** \addtogroup GRAS_API
3 \section GRAS_funct GRAS offers the following functionnalities
4 - <b>\ref GRAS_comm</b>: Exchanging messages between peers
5 - \ref GRAS_dd : any data which may transit on the network must be
6 described beforehand so that GRAS can handle the platform
7 heterogeneity and convert them if needed.
8 - \ref GRAS_sock : this is how to open a communication channel to
9 other processes, and retrive information about them.
10 - \ref GRAS_msg : communications are message oriented. You have to
11 describe all possible messages and their payload beforehand, and
12 can then attach callbacks to the arrival of a given kind of message.
13 - \ref GRAS_timer : this is how to program repetitive and delayed
14 tasks, not unlike cron(8) and at(1). This cannot be used to timeout
15 a function (like setitimer(2) or signal(2) games could do).
16 - <b>\ref GRAS_run</b>: Running both on top of the simulator and on
17 top of real platforms, and portability support.
18 - \ref GRAS_virtu : You naturally don't want to call the
19 gettimeofday(2) function in simulation mode since it would give
20 you the time on the host running the simulation, not the time in
21 the simulated world (you are belonging to).\n
22 This a system call virtualization layer, which also acts as a
24 - \ref GRAS_globals : The use of globals is forbidden since the
25 "processes" are threads in simulation mode. \n
26 This is how to let GRAS handle your globals properly.
27 - \ref GRAS_emul : Support to emulate code excution (ie, reporting
28 execution time into the simulator and having code sections specific
29 to simulation or to real mode).
31 \section GRAS_examples Examples
33 There is for now rather few examples of GRAS, but it's better than
41 The initiatic tour of the tutorial also contains several examples. The
42 most proeminent one is:
44 - \ref GRAS_tut_tour_explicitwait_use
46 \section GRAS_tut_presentation Tutorial
48 We even have a tutorial for the GRAS framework. It details in a
49 hopefully pedagogic order all the points of the API, along with example
50 of use for each of them. Unfortunately, it is not finished yet (the main
51 part missing is the one on how to describe data). Here is the table of
55 - \ref GRAS_tut_intro_what
56 - \ref GRAS_tut_intro_model
58 - \ref GRAS_tut_tour_install
59 - \ref GRAS_tut_tour_setup
60 - \ref GRAS_tut_tour_simpleexchange
61 - \ref GRAS_tut_tour_args
62 - \ref GRAS_tut_tour_callbacks
63 - \ref GRAS_tut_tour_globals
64 - \ref GRAS_tut_tour_logs
65 - \ref GRAS_tut_tour_timers
66 - \ref GRAS_tut_tour_exceptions
67 - \ref GRAS_tut_tour_rpc
68 - \ref GRAS_tut_tour_explicitwait
69 - \ref GRAS_tut_tour_message_recaping
71 \section GRAS_howto_presentation HOWTOsbis
73 The tutorial and the API documentation present the framework little
74 piece by little piece and provide a lot of information on each of them.
75 Quite orthogonally to this, the HOWTOs try to present transversal
76 aspects of the framework to give you some broader point of view on it.
77 How infortunate it is that only one such HOWTO exist for now...
80 - \ref GRAS_howto_design
83 /** @defgroup GRAS_comm Communication facilities */
84 /** @defgroup GRAS_run Virtualization */
85 /** @defgroup GRAS_ex Examples */
86 /** @defgroup GRAS_tut Tutorial */
88 #####################################################################
89 /** @addtogroup GRAS_comm
91 Here are the communication facilities. GRAS allows you to exchange
92 <i>messages</i> on <i>sockets</i> (which can be seen as pipes between
93 processes). On reception, messages start <i>callbacks</i> (that's the
94 default communication mode, not the only one). All messages of a given
95 type convey the same kind of data, and you have to describe it
98 Timers are also seen as a mean of communication (with yourself). It
99 allows you to run a repetitive task ("do this every N second until I tell
100 you to stop"), or to deffer a treatment ("do this in 3 sec").
103 /** @defgroup GRAS_dd Data description */
104 /** @defgroup GRAS_sock Sockets */
105 /** @defgroup GRAS_msg Messages */
106 /** @defgroup GRAS_timer Timers */
109 #####################################################################
110 /** @addtogroup GRAS_run
112 Virtualization facilities allow your code to run both on top of the simulator or in real setting.
116 /** @defgroup GRAS_globals Globals */
117 /** @defgroup GRAS_emul Emulation support */
118 /** @defgroup GRAS_virtu Syscalls */
122 #####################################################################
123 /** @addtogroup GRAS_ex
125 There is for now rather few examples of GRAS, but it's better than
133 The initiatic tour of the tutorial also contains several examples. The
134 most proeminent one is:
136 - \ref GRAS_tut_tour_explicitwait_use
138 There is some more examples in the distribution, under the directory
139 <tt>examples/gras</tt>.
142 #####################################################################
143 ######################### EXAMPLES #################################
144 #####################################################################
145 ---------------------------------------------------------------------
146 ------------------------- Ping Pong ---------------------------------
147 ---------------------------------------------------------------------
148 /** @defgroup GRAS_ex_ping Ping-Pong
151 This example implements the very classical ping-pong in GRAS. It
152 involves a client (initiating the ping-pong) and a server (answering to
155 It works the following way:
156 - Both the client and the server register all needed messages
157 - The server registers a callback to the ping message, which sends pong
159 - The client sends the ping message to the server, and waits for the
160 pong message as an answer.
162 This example resides in the <b>examples/gras/ping/ping.c</b> file. Yes, both
163 the code of the client and of the server is placed in the same file. See
164 the \ref GRAS_tut_tour_setup of the tutorial if wondering.
166 \section GRAS_ex_ping_toc Table of contents of the ping example
167 - \ref GRAS_ex_ping_common
168 - \ref GRAS_ex_ping_initial
169 - \ref GRAS_ex_ping_register
170 - \ref GRAS_ex_ping_server
171 - \ref GRAS_ex_ping_serdata
172 - \ref GRAS_ex_ping_sercb
173 - \ref GRAS_ex_ping_sermain
174 - \ref GRAS_ex_ping_client
175 - \ref GRAS_ex_ping_climain
179 \dontinclude gras/ping/ping_common.c
181 \section GRAS_ex_ping_common 1) Common code to the client and the server
183 \subsection GRAS_ex_ping_initial 1.a) Initial settings
185 Let's first load the module header and declare a logging category (see
186 \ref XBT_log for more info on logging).
191 The module header <tt>ping.h</tt> reads:
193 \dontinclude gras/ping/ping.h
198 \subsection GRAS_ex_ping_register 1.b) Register the messages
200 This function, called by both the client and the server is in charge of
201 declaring the existing messages to GRAS. Since the payload does not
202 involve any newly created types but only int, this is quite easy.
203 (to exchange more complicated types, see \ref GRAS_dd or
204 \ref GRAS_ex_mmrpc for an example).
206 \dontinclude gras/ping/ping_common.c
207 \skip register_messages
210 [Back to \ref GRAS_ex_ping_toc]
212 \section GRAS_ex_ping_server 2) Server's code
214 \subsection GRAS_ex_ping_serdata 2.a) The server's globals
216 In order to ensure the communication between the "main" and the callback
217 of the server, we need to declare some globals. We have to put them in a
218 struct definition so that they can be handled properly in GRAS (see the
219 \ref GRAS_tut_tour_globals for more info).
221 \dontinclude gras/ping/ping_server.c
225 \subsection GRAS_ex_ping_sercb 2.b) The callback to the ping message
227 Here is the callback run when the server receives any ping message (this
228 will be registered later by the server).
230 \skip server_cb_ping_handler
231 \until end_of_server_cb_ping_handler
233 \subsection GRAS_ex_ping_sermain 2.c) The "main" of the server
235 This is the "main" of the server. As explained in the tutorial, \ref
236 GRAS_tut_tour_setup, you must not write any main()
237 function yourself. Instead, you just have to write a regular function
238 like this one which will act as a main.
243 [Back to \ref GRAS_ex_ping_toc]
245 \section GRAS_ex_ping_client 3) Client's code
247 \subsection GRAS_ex_ping_climain 3.a) Client's "main" function
249 This function is quite straightforward, and the inlined comments should
250 be enough to understand it.
252 \dontinclude gras/ping/ping_client.c
256 [Back to \ref GRAS_ex_ping_toc]
259 ---------------------------------------------------------------------
260 --------------------- Simple Token Ring -----------------------------
261 ---------------------------------------------------------------------
263 /** @defgroup GRAS_ex_token Token Ring example
266 This example implements the token ring algorithm. It involves several
267 nodes arranged in a ring (each of them have a left and a right neighbour)
268 and exchanging a "token". This algorithm is one of the solution to ensure
269 the mutual exclusion between distributed processes. There is only one
270 token at any time, so the process in its possession is ensured to be the
271 only one having it. So, if there is an action you want all processes to
272 do alternativly, but you cannot afford to have two processes doing it at
273 the same time, let the process having the token doing it.
275 Actually, there is a lot of different token ring algorithms in the
276 litterature, so this example implements one of them: the simplest one.
277 The ring is static (no new node can join it, and you'll get trouble if
278 one node dies or leaves), and nothing is done for the case in which the
281 - \ref GRAS_ex_stoken_deploy
282 - \ref GRAS_ex_stoken_global
283 - \ref GRAS_ex_stoken_callback
284 - \ref GRAS_ex_stoken_main
286 \section GRAS_ex_stoken_deploy 1) Deployment file
288 Here is the deployment file:
289 \include examples/gras/mutual_exclusion/simple_token/simple_token.xml
291 The neighbour of each node is given at startup as command line argument.
292 Moreover, one of the nodes is instructed by a specific argument (the one
293 on Tremblay here) to create the token at the begining of the algorithm.
295 \section GRAS_ex_stoken_global 2) Global definition
297 The token is incarned by a specific message, which circulates from node
298 to node (the payload is an integer incremented at each hop). So, the most
299 important part of the code is the message callback, which forwards the
300 message to the next node. That is why we have to store all variable in a
301 global, as explained in the \ref GRAS_globals section.
303 \dontinclude examples/gras/mutual_exclusion/simple_token/simple_token.c
307 \section GRAS_ex_stoken_callback 3) The callback
309 Even if this is the core of this algorithm, this function is quite
312 \skip node_cb_stoken_handler
313 \until end_of_node_cb_stoken_handler
315 \section GRAS_ex_stoken_main 4) The main function
317 This function is splited in two parts: The first one performs all the
318 needed initialisations (points 1-7) while the end (point 8. below) calls
319 gras_msg_handle() as long as the planned amount of ring loops are not
327 ---------------------------------------------------------------------
328 -------------------------- MM RPC -----------------------------------
329 ---------------------------------------------------------------------
331 /** @defgroup GRAS_ex_mmrpc A simple RPC for matrix multiplication
334 This example implements a remote matrix multiplication. It involves a client
335 (creating the matrices and sending the multiplications requests) and a server
336 (computing the multiplication on client's behalf).
338 This example also constitutes a more advanced example of data description
339 mechanisms, since the message payload type is a bit more complicated than in
340 other examples such as the ping one (\ref GRAS_ex_ping).
342 It works the following way (not very different from the ping example):
343 - Both the client and the server register all needed messages and datatypes
344 - The server registers a callback to the "request" message, which computes
345 what needs to be and returns the result to the expeditor.
346 - The client creates two matrices, ask for their multiplication and check
349 This example resides in the <b>examples/gras/mmrpc/mmrpc.c</b> file. (See
350 the \ref GRAS_tut_tour_setup of the tutorial if wondering why both the server
351 and the client live in the same source file)
353 \section GRAS_ex_mmrpc_toc Table of contents of the mmrpc example
354 - \ref GRAS_ex_mmrpc_common
355 - \ref GRAS_ex_mmrpc_header
356 - \ref GRAS_ex_mmrpc_dataregister
357 - \ref GRAS_ex_mmrpc_logdef
358 - \ref GRAS_ex_mmrpc_msgregister
359 - \ref GRAS_ex_mmrpc_server
360 - \ref GRAS_ex_mmrpc_serinc
361 - \ref GRAS_ex_mmrpc_sercb
362 - \ref GRAS_ex_mmrpc_sermain
363 - \ref GRAS_ex_mmrpc_client
364 - \ref GRAS_ex_mmrpc_cliinc
365 - \ref GRAS_ex_mmrpc_climain
370 \section GRAS_ex_mmrpc_common 1) Common code to the client and the server (mmrpc_common.c and mmrpc.h)
373 \subsection GRAS_ex_mmrpc_header 1.a) Module header (mmrpc.h)
375 This loads the gras header and declare the function's prototypes as well
378 \dontinclude gras/mmrpc/mmrpc.h
383 \subsection GRAS_ex_mmrpc_dataregister 1.b) Register the data types (mmrpc.h)
385 The messages involved in a matrix of double. This type is automatically
386 known by the GRAS mecanism, using the gras_datadesc_matrix() function of the
389 \subsection GRAS_ex_mmrpc_logdef 1.c) Logging category definition (mmrpc_common.c)
391 Let's first load the module header and declare a logging category (see
392 \ref XBT_log for more info on logging). This logging category does live
393 in this file (ie the required symbols are defined here and declared as
394 "extern" in any other file using them). That is why we use
395 \ref XBT_LOG_NEW_DEFAULT_CATEGORY here and
396 \ref XBT_LOG_EXTERNAL_DEFAULT_CATEGORY in mmrpc_client.c and mmrpc_server.c.
398 \dontinclude gras/mmrpc/mmrpc_common.c
402 \subsection GRAS_ex_mmrpc_msgregister 1.d) Register the messages (mmrpc_common.c)
404 This function, called by both the client and the server is in charge of
405 declaring the existing messages to GRAS.
407 The datatype description builded that way can then be used to build an array datatype or
410 \skip register_messages
413 [Back to \ref GRAS_ex_mmrpc_toc]
415 \section GRAS_ex_mmrpc_server 2) Server's code (mmrpc_server.c)
417 \subsection GRAS_ex_mmrpc_serinc 2.a) Server intial settings
419 All module symbols live in the mmrpc_common.c file. We thus have to
420 define \ref XBT_DEFINE_TYPE_EXTERN to the preprocessor so that the
421 \ref XBT_DEFINE_TYPE symbols don't get included here. Likewise, we use
422 \ref XBT_LOG_EXTERNAL_DEFAULT_CATEGORY to get the log category in here.
424 \dontinclude gras/mmrpc/mmrpc_server.c
428 \subsection GRAS_ex_mmrpc_sercb 2.b) The callback to the mmrpc message
430 Here is the callback run when the server receives any mmrpc message (this
431 will be registered later by the server). Note the way we get the message
432 payload. In the ping example, there was one additional level of pointer
433 indirection (see \ref GRAS_ex_ping_sercb). This is because the payload is
434 an array here (ie a pointer) whereas it is a scalar in the ping example.
436 \skip server_cb_request_handler
437 \until end_of_server_cb_request_handler
439 \subsection GRAS_ex_mmrpc_sermain 2.c) The "main" of the server
441 This is the "main" of the server. As explained in the tutorial, \ref
442 GRAS_tut_tour_setup, you must not write any main()
443 function yourself. Instead, you just have to write a regular function
444 like this one which will act as a main.
449 [Back to \ref GRAS_ex_mmrpc_toc]
451 \section GRAS_ex_mmrpc_client 3) Client's code (mmrpc_client.c)
453 \subsection GRAS_ex_mmrpc_cliinc 2.a) Server intial settings
455 As for the server, some extra love is needed to make sure that automatic
456 datatype parsing and log categories do work even if we are using several
459 \dontinclude gras/mmrpc/mmrpc_client.c
463 \subsection GRAS_ex_mmrpc_climain 3.b) Client's "main" function
465 This function is quite straightforward, and the inlined comments should
466 be enough to understand it.
468 \dontinclude gras/mmrpc/mmrpc_client.c
472 [Back to \ref GRAS_ex_mmrpc_toc]
475 ---------------------------------------------------------------------
476 ---------------------------- Timers ---------------------------------
477 ---------------------------------------------------------------------
479 /** @defgroup GRAS_ex_timer Some timer games
482 This example fools around with the GRAS timers (\ref GRAS_timer). It is
483 mainly a regression test, since it uses almost all timer features.
485 The main program registers a repetititive task and a delayed one, and
486 then loops until the <tt>still_to_do</tt> variables of its globals reach
487 0. The delayed task set it to 5, and the repetititive one decrease it
488 each time. Here is an example of output:
489 \verbatim Initialize GRAS
491 [1108335471] Programming the repetitive_action with a frequency of 1.000000 sec
492 [1108335471] Programming the delayed_action for after 2.000000 sec
493 [1108335471] Have a rest
494 [1108335472] Canceling the delayed_action.
495 [1108335472] Re-programming the delayed_action for after 2.000000 sec
496 [1108335472] Repetitive_action has nothing to do yet
497 [1108335473] Repetitive_action has nothing to do yet
498 [1108335473] delayed_action setting globals->still_to_do to 5
499 [1108335474] repetitive_action decrementing globals->still_to_do. New value: 4
500 [1108335475] repetitive_action decrementing globals->still_to_do. New value: 3
501 [1108335476] repetitive_action decrementing globals->still_to_do. New value: 2
502 [1108335477] repetitive_action decrementing globals->still_to_do. New value: 1
503 [1108335478] repetitive_action decrementing globals->still_to_do. New value: 0
504 Exiting GRAS\endverbatim
507 - \ref GRAS_ex_timer_decl
508 - \ref GRAS_ex_timer_delay
509 - \ref GRAS_ex_timer_repeat
510 - \ref GRAS_ex_timer_main
514 \section GRAS_ex_timer_decl 1. Declarations and headers
518 \section GRAS_ex_timer_delay 2. Source code of the delayed action
519 \skip repetitive_action
520 \until end_of_repetitive_action
522 \section GRAS_ex_timer_repeat 3. Source code of the repetitive action
524 \until end_of_delayed_action
526 \section GRAS_ex_timer_main 4. Source code of main function