1 #####################################################################
2 ########################### CORE ###################################
3 #####################################################################
5 /** \addtogroup GRAS_API
7 \section GRAS_funct Offered functionnalities
8 - <b>Communication facilities</b>: Exchanging messages between peers
9 - \ref GRAS_dd : any data which may transit on the network must be
10 described beforehand so that GRAS can handle the platform
11 heterogeneity and convert them if needed.
12 - \ref GRAS_sock : this is how to open a communication channel to
13 other processes, and retrive information about them.
14 - \ref GRAS_msg : communications are message oriented. You have to
15 describe all possible messages and their payload beforehand, and
16 can then attach callbacks to the arrival of a given kind of message.
17 - \ref GRAS_timer : this is how to program repetitive and delayed
18 tasks, not unlike cron(8) and at(1). This cannot be used to timeout
19 a function (like setitimer(2) or signal(2) games could do).
20 - <b>Virtualization</b>: Running both on top of the simulator and on
21 top of real platforms, and portability support.
22 - \ref GRAS_virtu : You naturally don't want to call the
23 gettimeofday(2) function in simulation mode since it would give
24 you the time on the host running the simulation, not the time in
25 the simulated world (you are belonging to).\n
26 This a system call virtualization layer, which also acts as a
28 - \ref GRAS_globals : The use of globals is forbidden since the
29 "processes" are threads in simulation mode. \n
30 This is how to let GRAS handle your globals properly.
31 - \ref GRAS_emul : Support to emulate code excution (ie, reporting
32 execution time into the simulator and having code sections specific
33 to simulation or to real mode).
34 - <b>Project management tools</b>: Here are some tools which may help
35 you setting up a GRAS project.\n
36 Setting up and building a GRAS application is complicated by the
37 library schizoid. The code to setup the environment differs
38 depending on whether you run on the simulator on a real platform.
39 And then, you'll have to deal with the usual distributed
40 application development difficulties.
41 - \ref GRAS_main_generation : Since processes are threads in
42 simulation mode and regular processes in the real world, GRAS does
43 generate your main functions for you.
47 \section GRAS_example Examples
49 There is for now rather few examples of GRAS, but it's better than
57 DOXYGEN_NAVBAR_CHILD "main() and GRAS"=GRAS_main_generation.html
58 DOXYGEN_NAVBAR_CHILD "Compiling your GRAS project"=GRAS_compile.html
59 DOXYGEN_NAVBAR_CHILD "Ex: Ping-Pong"=GRAS_ex_ping.html
60 DOXYGEN_NAVBAR_CHILD "Ex: RPC"=GRAS_ex_mmrpc.html
61 DOXYGEN_NAVBAR_CHILD "Ex: Timers"=GRAS_ex_timer.html
65 /** @defgroup GRAS_dd Data description */
66 /** @defgroup GRAS_sock Sockets */
67 /** @defgroup GRAS_msg Messages */
68 /** @defgroup GRAS_timer Timers */
70 /** @defgroup GRAS_globals Globals */
71 /** @defgroup GRAS_emul Emulation support */
72 /** @defgroup GRAS_virtu Syscalls */
76 #####################################################################
77 ######################### EXTRA PAGES ##############################
78 #####################################################################
80 ---------------------------------------------------------------------
81 --------------------- main() generation -----------------------------
82 ---------------------------------------------------------------------
84 /** \page GRAS_main_generation main() and GRAS
86 <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]
87 <tr><td><b>Prev</b> <td> [\ref GRAS_emul]
88 <tr><td><b>Next</b> <td> [\ref GRAS_compile] </table></center>
91 \section GRAS_maingen_toc Table of content
93 - \ref GRAS_maingen_intro
94 - \ref GRAS_maingen_script
95 - \ref GRAS_maingen_make
99 \section GRAS_maingen_intro What's the matter with main() functions in GRAS?
101 In simulation mode, all processes are run as thread of the same process
102 while they are real processes in the real life. Unfortunately, the main
103 function of a real process must be called <tt>main</tt> while this
104 function must not use this name for threads.
106 To deal with this, you should call the main function of your processes
107 with another name (usually, the process function such as client, server,
108 or such). Then GRAS can generate the wrapper functions adapted to the
109 real and simulated modes.
111 \section GRAS_maingen_script Generating the main()s automatically
113 This is done by the gras_stub_generator program, which gets installed on
114 <tt>make install</tt> (the source resides in the tools/gras/ directory).
115 Here is the calling syntax:
116 \verbatim gras_stub_generator <project_name> <deployment_file.xml>\endverbatim
118 It parses the deployment file, searching for all the kind of processes
119 you have in your project. It then generates the following C files:
120 - a <tt>_<project_name>_<process_kind>.c</tt> file for each process kind you
122 They are used to launch your project in real life. They
123 contain a main() in charge of initializing the GRAS infrastructure and
124 launching your code afterward.
125 - a <tt>_<project_name>_simulator.c</tt> file.\n
126 This file is suited to the simulation mode. It contains a main()
127 function initializing the simulator and launching your project within.
129 For this to work, the name of process described in your deployment file
130 should match the name of a function in your code, which prototype is for
131 example: \verbatim int client(int argc,char *argv[]);\endverbatim
133 Unfortunately, all this is still partially documented. I guess I ought
134 to improve this situation somehow. In the meanwhile, check the generated
135 code and maybe also the GRAS \ref GRAS_example, sorry.
137 \section GRAS_maingen_make Integration within an hand-made Makefile
139 The easiest to set it up is to add the following chunk at the end of
140 your Makefile (or Makefile.am), putting the right values into NAME and
142 \verbatim NAME=your_project_name
143 PROCESSES=list of processes type in your project
145 $(foreach proc, $(PROCESSES), _$(NAME)_$(proc).c) _$(NAME)_simulator.c: $(NAME).c $(NAME)_deployment.xml
146 path/to/gras_stub_generator $(NAME) $(NAME)_deployment.xml >/dev/null
149 Of course, your personal millage may vary. For the \ref GRAS_ex_ping, may read:
150 \verbatim _ping_client.c _ping_server.c _ping_simulator.c: ping.c ping_deployment.xml
151 $(top_srcdir)/tools/gras/gras_stub_generator ping ping_deployment.xml >/dev/null
155 Actually, gras_stub_generator also generates some makefiles both for
156 local compilation and remote code distribution and installation. See the
157 section \ref GRAS_compile for more details.
161 ---------------------------------------------------------------------
162 ------------------------- Compiling ---------------------------------
163 ---------------------------------------------------------------------
165 /** \page GRAS_compile Compiling your GRAS project
167 <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]
168 <tr><td><b>Prev</b> <td> [\ref GRAS_main_generation]
169 <tr><td><b>Next</b> <td> [\ref GRAS_ex_ping] </table></center>
171 As explained in section \ref GRAS_main_generation, the
172 gras_stub_generator tool can be used to generate the system
173 initialization code in your projet. While we were at this, this tool
174 also generates the makefiles you will need to compile your project
177 Code source deployment and remote compilation also constitutes a
178 challenging area in distributed applications development. The GRASPE
179 (GRAS Platform Expender) tool was designed to make this less painful.
181 \section GRAS_compile_toc Table of content
183 - \ref GRAS_compile_local
184 - \ref GRAS_compile_local_install
185 - \ref GRAS_compile_local_helpfiles
186 - \ref GRAS_compile_local_makefile
187 - \ref GRAS_compile_remote
191 \section GRAS_compile_local Local compilation of GRAS projects
193 \subsection GRAS_compile_local_install Installing SimGrid and GRAS
195 To compile locally a GRAS project, you first need to install SimGrid on
196 your machine. Use the --prefix flag to the configure script to specify
197 where you want to install the toolkit (refere to section \ref
198 faq_compiling for more information)
200 \subsection GRAS_compile_local_helpfiles Simulation description files
202 Then, you will probably need to write a platform description file and
203 application deployment description file to feed the simulator with. This
204 part is unfortunatelly not documented enough. Files examples can be
205 found along with the MSG \ref MSG_ex_master_slave example.
207 \note yes, both platform and application description files are portable
208 between MSG and GRAS. Actually, there depend on the SURF, not on the
209 programming environment you use.
211 For the first try, you could probably reuse the provided platform file
212 as is while you will need to adapt the application file to fit your
215 To generate new platform files, we usually use the Tiers Topology
216 Generator (ask google about it) and annotate the generated graph with
217 home-made scripts to let them fit the SURF. Those scripts live in the
218 tools/platform_generation/ directory of the distribution.
220 \subsection GRAS_compile_local_makefile Generating a Makefile usable for your project
222 From the information contained in the application description file, the
223 gras_stub_generator tool can create a Makefile which can be used to
224 seamlessly compile your project. Just go to the directory containing all
225 your project files, and type:
227 \verbatim path/to/gras_stub_generator [project_name] [application_deployment.file] >/dev/null
230 The first argument is the name of your project, such as
231 "MyLovelyApplication" while the second one is the application deployment
234 Several files get generated by this command. One C file per kind of
235 process in your project (such as "master" and "slave") plus one C file
236 for simulating your project. All those files are (or should ;) described
237 in section \ref GRAS_main_generation.
239 The most intersting file in this context is
240 [project_name].Makefile.local (you can safely ignore the others for
241 now). To use it, simply type (from your project main directory):
243 \verbatim GRAS_ROOT=/path/to/simgrid/installation make -f [project_name].Makefile.local
246 And that's it, all the binaries are built and linked against the correct
249 \section GRAS_compile_remote Distribution and remote compilation of GRAS projects
251 Actually, there is two somehow parallel ways to do so since both Arnaud
252 and Martin gave it a try. Merging both approaches is underway. As usual,
253 if you want to help, you're welcome ;)
257 #####################################################################
258 ######################### EXAMPLES #################################
259 #####################################################################
261 ---------------------------------------------------------------------
262 ------------------------- Ping Pong ---------------------------------
263 ---------------------------------------------------------------------
265 /** \page GRAS_ex_ping The classical Ping-Pong in GRAS
267 <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]
268 <tr><td><b>Prev</b> <td> [\ref GRAS_compile]
269 <tr><td><b>Next</b> <td> [\ref GRAS_ex_mmrpc] </table></center>
271 This example implements the very classical ping-pong in GRAS. It
272 involves a client (initiating the ping-pong) and a server (answering to
275 It works the following way:
276 - Both the client and the server register all needed messages
277 - The server registers a callback to the ping message, which sends pong
279 - The client sends the ping message to the server, and waits for the
280 pong message as an answer.
282 This example resides in the <b>examples/gras/ping/ping.c</b> file. Yes, both
283 the code of the client and of the server is placed in the same file. See
284 the \ref GRAS_main_generation section if wondering.
286 \section GRAS_ex_ping_toc Table of contents of the ping example
287 - \ref GRAS_ex_ping_common
288 - \ref GRAS_ex_ping_initial
289 - \ref GRAS_ex_ping_register
290 - \ref GRAS_ex_ping_server
291 - \ref GRAS_ex_ping_serdata
292 - \ref GRAS_ex_ping_sercb
293 - \ref GRAS_ex_ping_sermain
294 - \ref GRAS_ex_ping_client
295 - \ref GRAS_ex_ping_climain
299 \dontinclude gras/ping/ping.c
301 \section GRAS_ex_ping_common 1) Common code to the client and the server
303 \subsection GRAS_ex_ping_initial 1.a) Initial settings
305 Let's first load the gras header and declare a logging category (see
306 \ref XBT_log for more info on logging).
311 \subsection GRAS_ex_ping_register 1.b) Register the messages
313 This function, called by both the client and the server is in charge of
314 declaring the existing messages to GRAS. Since the payload does not
315 involve any newly created types but only int, this is quite easy.
316 (to exchange more complicated types, see \ref GRAS_dd or
317 \ref GRAS_ex_mmrpc for an example).
319 \skip register_messages
322 [Back to \ref GRAS_ex_ping_toc]
324 \section GRAS_ex_ping_server 2) Server's code
326 \subsection GRAS_ex_ping_serdata 2.a) The server's globals
328 In order to ensure the communication between the "main" and the callback
329 of the server, we need to declare some globals. We have to put them in a
330 struct definition so that they can be handled properly in GRAS (see the
331 \ref GRAS_globals for more info).
336 \subsection GRAS_ex_ping_sercb 2.b) The callback to the ping message
338 Here is the callback run when the server receives any ping message (this
339 will be registered later by the server).
341 \skip server_cb_ping_handler
342 \until end_of_server_cb_ping_handler
344 \subsection GRAS_ex_ping_sermain 2.c) The "main" of the server
346 This is the "main" of the server. As explained in the \ref
347 GRAS_main_generation, you must not write any main()
348 function yourself. Instead, you just have to write a regular function
349 like this one which will act as a main.
354 [Back to \ref GRAS_ex_ping_toc]
356 \section GRAS_ex_ping_client 3) Client's code
358 \subsection GRAS_ex_ping_climain 3.a) Client's "main" function
360 This function is quite straightforward, and the inlined comments should
361 be enough to understand it.
366 [Back to \ref GRAS_ex_ping_toc]
369 ---------------------------------------------------------------------
370 -------------------------- MM RPC -----------------------------------
371 ---------------------------------------------------------------------
373 /** \page GRAS_ex_mmrpc A simple RPC for matrix multiplication
375 <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]
376 <tr><td><b>Prev</b> <td> [\ref GRAS_ex_ping]
377 <tr><td><b>Next</b> <td> [\ref GRAS_ex_timer] </table></center>
379 This example implements a remote matrix multiplication. It involves a client
380 (creating the matrices and sending the multiplications requests) and a server
381 (computing the multiplication on client's behalf).
383 This example also constitutes a more advanced example of data description
384 mechanisms, since the message payload type is a bit more complicated than in
385 other examples such as the ping one (\ref GRAS_ex_ping).
387 It works the following way (not very different from the ping example):
388 - Both the client and the server register all needed messages and datatypes
389 - The server registers a callback to the "request" message, which computes
390 what needs to be and returns the result to the expeditor.
391 - The client creates two matrices, ask for their multiplication and check
394 This example resides in the <b>examples/gras/mmrpc/mmrpc.c</b> file. (See
395 the \ref GRAS_main_generation section if wondering why both the server
396 and the client live in the same source file)
398 \section GRAS_ex_mmrpc_toc Table of contents of the mmrpc example
399 - \ref GRAS_ex_mmrpc_common
400 - \ref GRAS_ex_mmrpc_initial
401 - \ref GRAS_ex_mmrpc_dataregister
402 - \ref GRAS_ex_mmrpc_msgregister
403 - \ref GRAS_ex_mmrpc_server
404 - \ref GRAS_ex_mmrpc_sercb
405 - \ref GRAS_ex_mmrpc_sermain
406 - \ref GRAS_ex_mmrpc_client
407 - \ref GRAS_ex_mmrpc_climain
411 \dontinclude gras/mmrpc/mmrpc.c
413 \section GRAS_ex_mmrpc_common 1) Common code to the client and the server
415 \subsection GRAS_ex_mmrpc_initial 1.a) Initial settings
417 Let's first load the gras header, specify the matrix size and declare a
418 logging category (see \ref XBT_log for more info on logging).
423 \subsection GRAS_ex_mmrpc_dataregister 1.b) Register the data types
425 The messages involved in this example do use structures as payload,
426 so we have to declare it to GRAS. Hopefully, this can be done easily by enclosing
427 the structure declaration within a \ref GRAS_DEFINE_TYPE macro call. It will then copy this
428 declaration into an hidden string variable, which can be automatically parsed at
429 run time. Of course, the declaration is also copied unmodified by this macro, so that it
430 gets parsed by the compiler also.
432 There is some semantic that GRAS cannot guess alone and you need to <i>annotate</i>
433 your declaration to add some. For example, the ctn pointer can be a reference to an
434 object or a whole array (in which case you also has to specify its size). This is done
435 with the GRAS_ANNOTE call. It is removed from the text passed to the compiler, but it helps
436 GRAS getting some information about the semantic of your data. Here, it says that \a ctn is an
437 array, which size is the result of the operation \a rows * \a cols (with \a rows and \a cols
438 being the other fields of the structure).
440 Please note that this annotation mechanism is not as robust and cool as this example seems to
441 imply. If you want to use it yourself, you'd better use the exact right syntax, which is
442 detailed in the \ref GRAS_dd section.
444 \skip GRAS_DEFINE_TYPE
447 \subsection GRAS_ex_mmrpc_msgregister 1.c) Register the messages
449 This function, called by both the client and the server is in charge of
450 declaring the existing messages to GRAS. Note the use of the \ref gras_datadesc_by_symbol
451 function to parse and retrieve the structure declaration which were passed to \ref GRAS_DEFINE_TYPE
454 The datatype description builded that way can then be used to build an array datatype or
457 \skip register_messages
460 [Back to \ref GRAS_ex_mmrpc_toc]
462 \section GRAS_ex_mmrpc_server 2) Server's code
464 \subsection GRAS_ex_mmrpc_sercb 2.a) The callback to the mmrpc message
466 Here is the callback run when the server receives any mmrpc message (this
467 will be registered later by the server). Note the way we get the message
468 payload. In the ping example, there was one additional level of pointer
469 indirection (see \ref GRAS_ex_ping_sercb). This is because the payload is
470 an array here (ie a pointer) whereas it is a scalar in the ping example.
472 \skip server_cb_request_handler
473 \until end_of_server_cb_request_handler
475 \subsection GRAS_ex_mmrpc_sermain 2.b) The "main" of the server
477 This is the "main" of the server. As explained in the \ref
478 GRAS_main_generation, you must not write any main()
479 function yourself. Instead, you just have to write a regular function
480 like this one which will act as a main.
485 [Back to \ref GRAS_ex_mmrpc_toc]
487 \section GRAS_ex_mmrpc_client 3) Client's code
489 \subsection GRAS_ex_mmrpc_climain 3.a) Client's "main" function
491 This function is quite straightforward, and the inlined comments should
492 be enough to understand it.
497 [Back to \ref GRAS_ex_mmrpc_toc]
500 ---------------------------------------------------------------------
501 ---------------------------- Timers ---------------------------------
502 ---------------------------------------------------------------------
504 /** \page GRAS_ex_timer Some timer games
506 <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]
507 <tr><td><b>Prev</b> <td> [\ref GRAS_ex_mmrpc]
508 <tr><td> Next <td> </table></center>
510 This example fools around with the GRAS timers (\ref GRAS_timer). It is
511 mainly a regression test, since it uses almost all timer features.
513 The main program registers a repetititive task and a delayed one, and
514 then loops until the <tt>still_to_do</tt> variables of its globals reach
515 0. The delayed task set it to 5, and the repetititive one decrease it
516 each time. Here is an example of output:
517 \verbatim Initialize GRAS
519 [1108335471] Programming the repetitive_action with a frequency of 1.000000 sec
520 [1108335471] Programming the delayed_action for after 2.000000 sec
521 [1108335471] Have a rest
522 [1108335472] Canceling the delayed_action.
523 [1108335472] Re-programming the delayed_action for after 2.000000 sec
524 [1108335472] Repetitive_action has nothing to do yet
525 [1108335473] Repetitive_action has nothing to do yet
526 [1108335473] delayed_action setting globals->still_to_do to 5
527 [1108335474] repetitive_action decrementing globals->still_to_do. New value: 4
528 [1108335475] repetitive_action decrementing globals->still_to_do. New value: 3
529 [1108335476] repetitive_action decrementing globals->still_to_do. New value: 2
530 [1108335477] repetitive_action decrementing globals->still_to_do. New value: 1
531 [1108335478] repetitive_action decrementing globals->still_to_do. New value: 0
532 Exiting GRAS\endverbatim
535 - \ref GRAS_ex_timer_decl
536 - \ref GRAS_ex_timer_delay
537 - \ref GRAS_ex_timer_repeat
538 - \ref GRAS_ex_timer_main
542 \section GRAS_ex_timer_decl 1. Declarations and headers
546 \section GRAS_ex_timer_delay 2. Source code of the delayed action
547 \skip repetitive_action
548 \until end_of_repetitive_action
550 \section GRAS_ex_timer_repeat 3. Source code of the repetitive action
552 \until end_of_delayed_action
554 \section GRAS_ex_timer_main 4. Source code of main function