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_cond: How to declare specific code for the simulation mode
33 - <b>Project management tools</b>: Here are some tools which may help
34 you setting up a GRAS project.\n
35 Setting up and building a GRAS application is complicated by the
36 library schizoid. The code to setup the environment differs
37 depending on whether you run on the simulator on a real platform.
38 And then, you'll have to deal with the usual distributed
39 application development difficulties.
40 - \ref GRAS_main_generation: Since processes are threads in
41 simulation mode and regular processes in the real world, GRAS does
42 generate your main functions for you.
46 \section GRAS_example Examples
48 There is for now rather few examples of GRAS, but it's better than
55 /** \defgroup GRAS_dd Data description */
56 /** \defgroup GRAS_sock Sockets */
57 /** \defgroup GRAS_msg Messages */
58 /** \defgroup GRAS_timer Timers */
60 /** \defgroup GRAS_globals Globals */
61 /** \defgroup GRAS_cond Conditional execution */
62 /** \defgroup GRAS_virtu Syscalls */
66 #####################################################################
67 ######################### EXTRA PAGES ##############################
68 #####################################################################
70 ---------------------------------------------------------------------
71 --------------------- main() generation -----------------------------
72 ---------------------------------------------------------------------
74 /** \page GRAS_main_generation main() and GRAS
76 <center>[\ref GRAS_API]</center>
78 \section GRAS_maingen_toc Table of content
80 - \ref GRAS_maingen_intro
81 - \ref GRAS_maingen_script
82 - \ref GRAS_maingen_make
86 \section GRAS_maingen_intro What's the matter with main() functions in GRAS?
88 In simulation mode, all processes are run as thread of the same process
89 while they are real processes in the real life. Unfortunately, the main
90 function of a real process must be called <tt>main</tt> while this
91 function must not use this name for threads.
93 To deal with this, you should call the main function of your processes
94 with another name (usually, the process function such as client, server,
95 or such). Then GRAS can generate the wrapper functions adapted to the
96 real and simulated modes.
98 \section GRAS_maingen_script Generating the main()s automatically
100 This is done by the gras_stub_generator program, which gets installed on
101 <tt>make install</tt> (the source resides in the tools/gras/ directory).
102 Here is the calling syntax:
103 \verbatim gras_stub_generator <project_name> <deployment_file.xml>\endverbatim
105 It parses the deployment file, searching for all the kind of processes
106 you have in your project. It then generates the following C files:
107 - a <tt>_<project_name>_<process_kind>.c</tt> file for each process kind you
109 They are used to launch your project in real life. They
110 contain a main() in charge of initializing the GRAS infrastructure and
111 launching your code afterward.
112 - a <tt>_<project_name>_simulator.c</tt> file.\n
113 This file is suited to the simulation mode. It contains a main()
114 function initializing the simulator and launching your project within.
116 For this to work, the name of process described in your deployment file
117 should match the name of a function in your code, which prototype is for
118 example: \verbatim int client(int argc,char *argv[]);\endverbatim
120 Unfortunately, all this is still partially documented. I guess I ought
121 to improve this situation somehow. In the meanwhile, check the generated
122 code and maybe also the GRAS \ref GRAS_example, sorry.
124 \section GRAS_maingen_make Integration within an hand-made Makefile
126 The easiest to set it up is to add the following chunk at the end of
127 your Makefile (or Makefile.am), putting the right values into NAME and
129 \verbatim NAME=your_project_name
130 PROCESSES=list of processes type in your project
132 $(foreach proc, $(PROCESSES), _$(NAME)_$(proc).c) _$(NAME)_simulator.c: $(NAME).c $(NAME)_deployment.xml
133 path/to/gras_stub_generator $(NAME) $(NAME)_deployment.xml >/dev/null
136 Of course, your personal millage may vary. For the \ref GRAS_ex_ping, may read:
137 \verbatim _ping_client.c _ping_server.c _ping_simulator.c: ping.c ping_deployment.xml
138 $(top_srcdir)/tools/gras/gras_stub_generator ping ping_deployment.xml >/dev/null
142 Actually, gras_stub_generator also generates some makefiles both for
143 local compilation and remote code distribution and installation. See the
144 section \ref GRAS_compile for more details.
148 ---------------------------------------------------------------------
149 ------------------------- Compiling ---------------------------------
150 ---------------------------------------------------------------------
152 /** \page GRAS_compile Compiling your GRAS project
154 <center>[\ref GRAS_API]</center>
156 As explained in section \ref GRAS_main_generation, the
157 gras_stub_generator tool can be used to generate the system
158 initialization code in your projet. While we were at this, this tool
159 also generates the makefiles you will need to compile your project
162 Code source deployment and remote compilation also constitutes a
163 challenging area in distributed applications development. The GRASPE
164 (GRAS Platform Expender) tool was designed to make this less painful.
166 \section GRAS_compile_toc Table of content
168 - \ref GRAS_compile_local
169 - \ref GRAS_compile_local_install
170 - \ref GRAS_compile_local_helpfiles
171 - \ref GRAS_compile_local_makefile
172 - \ref GRAS_compile_remote
176 \section GRAS_compile_local Local compilation of GRAS projects
178 \subsection GRAS_compile_local_install Installing SimGrid and GRAS
180 To compile locally a GRAS project, you first need to install SimGrid on
181 your machine. Use the --prefix flag to the configure script to specify
182 where you want to install the toolkit (refere to section \ref
183 faq_compiling for more information)
185 \subsection GRAS_compile_local_helpfiles Simulation description files
187 Then, you will probably need to write a platform description file and
188 application deployment description file to feed the simulator with. This
189 part is unfortunatelly not documented enough. Files examples can be
190 found along with the MSG \ref MSG_ex_master_slave example.
192 \note yes, both platform and application description files are portable
193 between MSG and GRAS. Actually, there depend on the SURF, not on the
194 programming environment you use.
196 For the first try, you could probably reuse the provided platform file
197 as is while you will need to adapt the application file to fit your
200 To generate new platform files, we usually use the Tiers Topology
201 Generator (ask google about it) and annotate the generated graph with
202 home-made scripts to let them fit the SURF. Those scripts live in the
203 tools/platform_generation/ directory of the distribution.
205 \subsection GRAS_compile_local_makefile Generating a Makefile usable for your project
207 From the information contained in the application description file, the
208 gras_stub_generator tool can create a Makefile which can be used to
209 seamlessly compile your project. Just go to the directory containing all
210 your project files, and type:
212 \verbatim path/to/gras_stub_generator [project_name] [application_deployment.file] >/dev/null
215 The first argument is the name of your project, such as
216 "MyLovelyApplication" while the second one is the application deployment
219 Several files get generated by this command. One C file per kind of
220 process in your project (such as "master" and "slave") plus one C file
221 for simulating your project. All those files are (or should ;) described
222 in section \ref GRAS_main_generation.
224 The most intersting file in this context is
225 [project_name].Makefile.local (you can safely ignore the others for
226 now). To use it, simply type (from your project main directory):
228 \verbatim GRAS_ROOT=/path/to/simgrid/installation make -f [project_name].Makefile.local
231 And that's it, all the binaries are built and linked against the correct
234 \section GRAS_compile_remote Distribution and remote compilation of GRAS projects
236 Actually, there is two somehow parallel ways to do so since both Arnaud
237 and Martin gave it a try. Merging both approaches is underway. As usual,
238 if you want to help, you're welcome ;)
242 #####################################################################
243 ######################### EXAMPLES #################################
244 #####################################################################
246 ---------------------------------------------------------------------
247 ------------------------- Ping Pong ---------------------------------
248 ---------------------------------------------------------------------
250 /** \page GRAS_ex_ping The classical Ping-Pong in GRAS
252 <center>[\ref GRAS_API]</center>
254 This example implements the very classical ping-pong in GRAS. It
255 involves a client (initiating the ping-pong) and a server (answering to
258 It works the following way:
259 - Both the client and the server register all needed messages
260 - The server registers a callback to the ping message, which sends pong
262 - The client sends the ping message to the server, and waits for the
263 pong message as an answer.
265 This example resides in the <b>examples/gras/ping/ping.c</b> file. Yes, both
266 the code of the client and of the server is placed in the same file. See
267 the \ref GRAS_main_generation section if wondering.
269 \section GRAS_ex_ping_over Overview
270 - \ref GRAS_ex_ping_common
271 - \ref GRAS_ex_ping_initial
272 - \ref GRAS_ex_ping_register
273 - \ref GRAS_ex_ping_server
274 - \ref GRAS_ex_ping_serdata
275 - \ref GRAS_ex_ping_sercb
276 - \ref GRAS_ex_ping_sermain
277 - \ref GRAS_ex_ping_client
278 - \ref GRAS_ex_ping_climain
282 \dontinclude gras/ping/ping.c
284 \section GRAS_ex_ping_common 1) Common code to the client and the server
286 \subsection GRAS_ex_ping_initial 1.a) Initial settings
288 Let's first load the gras header and declare a logging category (see
289 \ref XBT_log for more info on logging).
294 \subsection GRAS_ex_ping_register 1.b) Register the messages
296 This function, called by both the client and the server is in charge of
297 declaring the existing messages to GRAS. Since the payload does not
298 involve any newly created types but only int, this is quite easy.
299 (to exchange more complicated types, see \ref GRAS_dd)
301 \skip register_messages
304 \section GRAS_ex_ping_server 2) Server's code
306 \subsection GRAS_ex_ping_serdata 2.a) The server's globals
308 In order to ensure the communication between the "main" and the callback
309 of the server, we need to declare some globals. We have to put them in a
310 struct definition so that they can be handled properly in GRAS (see the
311 \ref GRAS_globals for more info).
316 \subsection GRAS_ex_ping_sercb 2.b) The callback to the ping message
318 Here is the callback run when the server receives any ping message (this
319 will be registered later by the server).
321 \skip server_cb_ping_handler
322 \until end_of_server_cb_ping_handler
324 \subsection GRAS_ex_ping_sermain 2.c) The "main" of the server
326 This is the "main" of the server. As explained in the \ref
327 GRAS_main_generation, you don't have to (and shouldn't) write any main()
328 function yourself. Instead, you just have to write a regular function
329 like this one which will act as a main.
334 \section GRAS_ex_ping_client 3) Client's code
336 \subsection GRAS_ex_ping_climain 3.a) Client's "main" function
342 ---------------------------------------------------------------------
343 ---------------------------- Timers ---------------------------------
344 ---------------------------------------------------------------------
346 /** \page GRAS_ex_timer Some timer games
348 <center>[\ref GRAS_API]</center>
350 This example fools around with the GRAS timers (\ref GRAS_timer). It is
351 mainly a regression test, since it uses almost all timer features.
353 The main program registers a repetititive task and a delayed one, and
354 then loops until the <tt>still_to_do</tt> variables of its globals reach
355 0. The delayed task set it to 5, and the repetititive one decrease it
356 each time. Here is an example of output:
357 \verbatim Initialize GRAS
359 [1108335471] Programming the repetitive_action with a frequency of 1.000000 sec
360 [1108335471] Programming the delayed_action for after 2.000000 sec
361 [1108335471] Have a rest
362 [1108335472] Canceling the delayed_action.
363 [1108335472] Re-programming the delayed_action for after 2.000000 sec
364 [1108335472] Repetitive_action has nothing to do yet
365 [1108335473] Repetitive_action has nothing to do yet
366 [1108335473] delayed_action setting globals->still_to_do to 5
367 [1108335474] repetitive_action decrementing globals->still_to_do. New value: 4
368 [1108335475] repetitive_action decrementing globals->still_to_do. New value: 3
369 [1108335476] repetitive_action decrementing globals->still_to_do. New value: 2
370 [1108335477] repetitive_action decrementing globals->still_to_do. New value: 1
371 [1108335478] repetitive_action decrementing globals->still_to_do. New value: 0
372 Exiting GRAS\endverbatim
375 - \ref GRAS_ex_timer_decl
376 - \ref GRAS_ex_timer_delay
377 - \ref GRAS_ex_timer_repeat
378 - \ref GRAS_ex_timer_main
382 \section GRAS_ex_timer_decl 1. Declarations and headers
386 \section GRAS_ex_timer_delay 2. Source code of the delayed action
387 \skip repetitive_action
388 \until end_of_repetitive_action
390 \section GRAS_ex_timer_repeat 3. Source code of the repetitive action
392 \until end_of_delayed_action
394 \section GRAS_ex_timer_main 4. Source code of main function