Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
635e0ea85f1a7a4c9763d5f89b4aa6513782554c
[simgrid.git] / doc / module-gras.doc
1 #####################################################################
2 ###########################  CORE ###################################
3 #####################################################################
4
5 /** \addtogroup GRAS_API
6   
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
27           portability layer.
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.
44        - \ref GRAS_compile
45      
46           
47     \section GRAS_example Examples
48       
49     There is for now rather few examples of GRAS, but it's better than
50     nothing, isn't it?
51     
52        - \ref GRAS_ex_ping 
53        - \ref GRAS_ex_timer
54                
55     @{ */     
56        /** \defgroup GRAS_dd      Data description      */       
57        /** \defgroup GRAS_sock    Sockets               */           
58        /** \defgroup GRAS_msg     Messages              */               
59        /** \defgroup GRAS_timer   Timers                */               
60          
61        /** \defgroup GRAS_globals Globals               */ 
62        /** \defgroup GRAS_emul    Emulation support */ 
63        /** \defgroup GRAS_virtu   Syscalls              */ 
64
65 /** @} */
66
67 #####################################################################
68 #########################  EXTRA PAGES ##############################
69 #####################################################################
70
71 ---------------------------------------------------------------------
72 --------------------- main() generation -----------------------------
73 ---------------------------------------------------------------------
74
75 /** \page GRAS_main_generation main() and GRAS
76
77     <center>[\ref GRAS_API]</center>
78
79     \section GRAS_maingen_toc Table of content
80      
81      - \ref GRAS_maingen_intro
82      - \ref GRAS_maingen_script
83      - \ref GRAS_maingen_make
84     
85     <hr>
86
87     \section GRAS_maingen_intro What's the matter with main() functions in GRAS?
88
89     In simulation mode, all processes are run as thread of the same process
90     while they are real processes in the real life. Unfortunately, the main
91     function of a real process must be called <tt>main</tt> while this
92     function must not use this name for threads.
93     
94     To deal with this, you should call the main function of your processes
95     with another name (usually, the process function such as client, server,
96     or such). Then GRAS can generate the wrapper functions adapted to the
97     real and simulated modes.
98
99     \section GRAS_maingen_script Generating the main()s automatically
100     
101     This is done by the gras_stub_generator program, which gets installed on
102     <tt>make install</tt> (the source resides in the tools/gras/ directory).
103     Here is the calling syntax: 
104     \verbatim gras_stub_generator <project_name> <deployment_file.xml>\endverbatim
105     
106     It parses the deployment file, searching for all the kind of processes
107     you have in your project. It then generates the following C files:
108      - a <tt>_<project_name>_<process_kind>.c</tt> file for each process kind you
109        have\n
110        They are used to launch your project in real life. They
111        contain a main() in charge of initializing the GRAS infrastructure and
112        launching your code afterward.
113      - a <tt>_<project_name>_simulator.c</tt> file.\n
114        This file is suited to the simulation mode. It contains a main()
115        function initializing the simulator and launching your project within.
116     
117     For this to work, the name of process described in your deployment file
118     should match the name of a function in your code, which prototype is for
119     example: \verbatim int client(int argc,char *argv[]);\endverbatim
120     
121     Unfortunately, all this is still partially documented. I guess I ought
122     to improve this situation somehow. In the meanwhile, check the generated 
123     code and maybe also the GRAS \ref GRAS_example, sorry. 
124         
125     \section GRAS_maingen_make Integration within an hand-made Makefile 
126     
127     The easiest to set it up is to add the following chunk at the end of
128     your Makefile (or Makefile.am), putting the right values into NAME and
129     PROCESSES.
130 \verbatim NAME=your_project_name
131  PROCESSES=list of processes type in your project
132
133  $(foreach proc, $(PROCESSES), _$(NAME)_$(proc).c) _$(NAME)_simulator.c: $(NAME).c $(NAME)_deployment.xml
134         path/to/gras_stub_generator $(NAME) $(NAME)_deployment.xml >/dev/null
135 \endverbatim
136
137     Of course, your personal millage may vary. For the \ref GRAS_ex_ping, may read:
138 \verbatim _ping_client.c _ping_server.c _ping_simulator.c: ping.c ping_deployment.xml 
139         $(top_srcdir)/tools/gras/gras_stub_generator ping ping_deployment.xml >/dev/null
140 \endverbatim
141
142    \warning 
143    Actually, gras_stub_generator also generates some makefiles both for
144    local compilation and remote code distribution and installation. See the
145    section \ref GRAS_compile for more details.
146
147 */
148
149 ---------------------------------------------------------------------
150 ------------------------- Compiling ---------------------------------
151 ---------------------------------------------------------------------
152
153 /** \page GRAS_compile Compiling your GRAS project
154
155     <center>[\ref GRAS_API]</center>
156
157     As explained in section \ref GRAS_main_generation, the
158     gras_stub_generator tool can be used to generate the system
159     initialization code in your projet. While we were at this, this tool
160     also generates the makefiles you will need to compile your project
161     properly.
162     
163     Code source deployment and remote compilation also constitutes a
164     challenging area in distributed applications development. The GRASPE
165     (GRAS Platform Expender) tool was designed to make this less painful.
166
167     \section GRAS_compile_toc Table of content
168     
169       - \ref GRAS_compile_local
170         - \ref GRAS_compile_local_install
171         - \ref GRAS_compile_local_helpfiles
172         - \ref GRAS_compile_local_makefile
173       - \ref GRAS_compile_remote
174       
175     <hr>
176     
177     \section GRAS_compile_local Local compilation of GRAS projects
178     
179     \subsection GRAS_compile_local_install Installing SimGrid and GRAS
180     
181     To compile locally a GRAS project, you first need to install SimGrid on
182     your machine. Use the --prefix flag to the configure script to specify
183     where you want to install the toolkit (refere to section \ref
184     faq_compiling for more information)
185     
186     \subsection GRAS_compile_local_helpfiles Simulation description files
187     
188     Then, you will probably need to write a platform description file and
189     application deployment description file to feed the simulator with. This
190     part is unfortunatelly not documented enough. Files examples can be
191     found along with the MSG \ref MSG_ex_master_slave example. 
192
193     \note yes, both platform and application description files are portable
194     between MSG and GRAS. Actually, there depend on the SURF, not on the
195     programming environment you use.
196     
197     For the first try, you could probably reuse the provided platform file
198     as is while you will need to adapt the application file to fit your
199     needs. 
200     
201     To generate new platform files, we usually use the Tiers Topology
202     Generator (ask google about it) and annotate the generated graph with
203     home-made scripts to let them fit the SURF. Those scripts live in the
204     tools/platform_generation/ directory of the distribution.
205     
206     \subsection GRAS_compile_local_makefile Generating a Makefile usable for your project
207     
208     From the information contained in the application description file, the
209     gras_stub_generator tool can create a Makefile which can be used to
210     seamlessly compile your project. Just go to the directory containing all
211     your project files, and type:
212     
213 \verbatim path/to/gras_stub_generator [project_name] [application_deployment.file] >/dev/null
214 \endverbatim
215
216     The first argument is the name of your project, such as
217     "MyLovelyApplication" while the second one is the application deployment
218     file. 
219     
220     Several files get generated by this command. One C file per kind of
221     process in your project (such as "master" and "slave") plus one C file
222     for simulating your project. All those files are (or should ;) described
223     in section \ref GRAS_main_generation.
224     
225     The most intersting file in this context is
226     [project_name].Makefile.local (you can safely ignore the others for
227     now). To use it, simply type (from your project main directory):
228     
229 \verbatim GRAS_ROOT=/path/to/simgrid/installation make -f [project_name].Makefile.local
230 \endverbatim
231     
232     And that's it, all the binaries are built and linked against the correct
233     libraries.
234     
235     \section GRAS_compile_remote Distribution and remote compilation of GRAS projects
236     
237     Actually, there is two somehow parallel ways to do so since both Arnaud
238     and Martin gave it a try. Merging both approaches is underway. As usual,
239     if you want to help, you're welcome ;)
240     
241 */
242
243 #####################################################################
244 #########################  EXAMPLES #################################
245 #####################################################################
246
247 ---------------------------------------------------------------------
248 ------------------------- Ping Pong ---------------------------------
249 ---------------------------------------------------------------------
250
251 /** \page GRAS_ex_ping The classical Ping-Pong in GRAS
252
253     <center>[\ref GRAS_API]</center>
254
255     This example implements the very classical ping-pong in GRAS. It
256     involves a client (initiating the ping-pong) and a server (answering to 
257     client's requests).
258
259     It works the following way:
260      - Both the client and the server register all needed messages
261      - The server registers a callback to the ping message, which sends pong
262        to the expeditor
263      - The client sends the ping message to the server, and waits for the
264        pong message as an answer.
265  
266     This example resides in the <b>examples/gras/ping/ping.c</b> file. Yes, both
267     the code of the client and of the server is placed in the same file. See
268     the \ref GRAS_main_generation section if wondering.
269
270     \section GRAS_ex_ping_over Overview
271       - \ref GRAS_ex_ping_common
272         - \ref GRAS_ex_ping_initial
273         - \ref GRAS_ex_ping_register
274       - \ref GRAS_ex_ping_server
275         - \ref GRAS_ex_ping_serdata
276         - \ref GRAS_ex_ping_sercb
277         - \ref GRAS_ex_ping_sermain
278       - \ref GRAS_ex_ping_client
279         - \ref GRAS_ex_ping_climain
280         
281     <hr>
282
283     \dontinclude gras/ping/ping.c
284     
285     \section GRAS_ex_ping_common 1) Common code to the client and the server 
286     
287     \subsection GRAS_ex_ping_initial 1.a) Initial settings
288     
289     Let's first load the gras header and declare a logging category (see
290     \ref XBT_log for more info on logging).
291     
292     \skip include
293     \until XBT_LOG
294
295     \subsection GRAS_ex_ping_register 1.b) Register the messages
296     
297     This function, called by both the client and the server is in charge of
298     declaring the existing messages to GRAS. Since the payload does not
299     involve any newly created types but only int, this is quite easy. 
300     (to exchange more complicated types, see \ref GRAS_dd)
301     
302     \skip register_messages
303     \until }
304
305     \section GRAS_ex_ping_server 2) Server's code
306     
307     \subsection GRAS_ex_ping_serdata 2.a) The server's globals
308
309     In order to ensure the communication between the "main" and the callback
310     of the server, we need to declare some globals. We have to put them in a
311     struct definition so that they can be handled properly in GRAS (see the
312     \ref GRAS_globals for more info).
313
314     \skip typedef struct
315     \until }
316     
317     \subsection GRAS_ex_ping_sercb 2.b) The callback to the ping message
318
319     Here is the callback run when the server receives any ping message (this
320     will be registered later by the server).
321     
322     \skip server_cb_ping_handler
323     \until end_of_server_cb_ping_handler
324
325     \subsection GRAS_ex_ping_sermain 2.c) The "main" of the server
326     
327     This is the "main" of the server. As explained in the \ref
328     GRAS_main_generation, you don't have to (and shouldn't) write any main()
329     function yourself. Instead, you just have to write a regular function
330     like this one which will act as a main.
331     
332     \skip server
333     \until end_of_server
334     
335     \section GRAS_ex_ping_client 3) Client's code
336     
337     \subsection GRAS_ex_ping_climain 3.a) Client's "main" function
338     
339     \skip client
340     \until end_of_client
341   */
342
343 ---------------------------------------------------------------------
344 ---------------------------- Timers ---------------------------------
345 ---------------------------------------------------------------------
346
347 /** \page GRAS_ex_timer Some timer games
348
349     <center>[\ref GRAS_API]</center>
350
351     This example fools around with the GRAS timers (\ref GRAS_timer). It is
352     mainly a regression test, since it uses almost all timer features.
353     
354     The main program registers a repetititive task and a delayed one, and
355     then loops until the <tt>still_to_do</tt> variables of its globals reach
356     0. The delayed task set it to 5, and the repetititive one decrease it
357     each time. Here is an example of output:
358 \verbatim Initialize GRAS
359  Initialize XBT
360  [1108335471] Programming the repetitive_action with a frequency of 1.000000 sec
361  [1108335471] Programming the delayed_action for after 2.000000 sec
362  [1108335471] Have a rest
363  [1108335472] Canceling the delayed_action.
364  [1108335472] Re-programming the delayed_action for after 2.000000 sec
365  [1108335472] Repetitive_action has nothing to do yet
366  [1108335473] Repetitive_action has nothing to do yet
367  [1108335473] delayed_action setting globals->still_to_do to 5
368  [1108335474] repetitive_action decrementing globals->still_to_do. New value: 4
369  [1108335475] repetitive_action decrementing globals->still_to_do. New value: 3
370  [1108335476] repetitive_action decrementing globals->still_to_do. New value: 2
371  [1108335477] repetitive_action decrementing globals->still_to_do. New value: 1
372  [1108335478] repetitive_action decrementing globals->still_to_do. New value: 0
373  Exiting GRAS\endverbatim
374
375     Source code:
376      - \ref GRAS_ex_timer_decl
377      - \ref GRAS_ex_timer_delay
378      - \ref GRAS_ex_timer_repeat
379      - \ref GRAS_ex_timer_main
380
381     \dontinclude timer.c
382     
383     \section GRAS_ex_timer_decl   1. Declarations and headers
384     \skip include
385     \until my_globals
386     
387     \section GRAS_ex_timer_delay  2. Source code of the delayed action
388     \skip repetitive_action
389     \until end_of_repetitive_action
390     
391     \section GRAS_ex_timer_repeat 3. Source code of the repetitive action
392     \skip delayed_action
393     \until end_of_delayed_action
394     
395     \section GRAS_ex_timer_main   4. Source code of main function
396     \skip client
397     \until end_of_client
398 */