1 #####################################################################
2 ########################### CORE ###################################
3 #####################################################################
5 /** \addtogroup GRAS_API
7 \section GRAS_funct Offered functionnalities
8 - <b>\ref GRAS_comm</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>\ref GRAS_run</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>\ref GRAS_code</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
58 /** @defgroup GRAS_comm Communication facilities */
59 /** @defgroup GRAS_run Virtualization */
60 /** @defgroup GRAS_code Project and code management */
61 /** @defgroup GRAS_ex Examples */
62 /** @defgroup GRAS_tut GRAS Tutorial */
64 #####################################################################
65 /** @addtogroup GRAS_comm
67 Here are the communication facilities. GRAS allows you to exchange
68 <i>messages</i> on <i>sockets</i> (which can be seen as pipes between
69 processes). On reception, messages start <i>callbacks</i> (that's the
70 default communication mode, not the only one). All messages of a given
71 type convey the same kind of data, and you have to describe it
74 Timers are also seen as a mean of communication (with yourself). It
75 allows you to run a repetitive task ("do this every N second until I tell
76 you to stop"), or to deffer a treatment ("do this in 3 sec").
79 /** @defgroup GRAS_dd Data description */
80 /** @defgroup GRAS_sock Sockets */
81 /** @defgroup GRAS_msg Messages */
82 /** @defgroup GRAS_timer Timers */
85 #####################################################################
86 /** @addtogroup GRAS_run
88 Virtualization facilities allow your code to run both on top of the simulator or in real setting.
92 /** @defgroup GRAS_globals Globals */
93 /** @defgroup GRAS_emul Emulation support */
94 /** @defgroup GRAS_virtu Syscalls */
98 #####################################################################
99 /** @addtogroup GRAS_code
101 Here is how to setup your code when you want to use GRAS. You will also
102 learn how to get the most repetitive parts of your code generated
105 (use the tabs on top of the page to navigate)
108 DOXYGEN_NAVBAR_LABEL="Project management"
109 DOXYGEN_NAVBAR_CHILD "main() and GRAS"=GRAS_main_generation.html
110 DOXYGEN_NAVBAR_CHILD "Compiling your GRAS project"=GRAS_compile.html
114 #####################################################################
115 /** @addtogroup GRAS_ex
117 There is for now rather few examples of GRAS, but it's better than
126 DOXYGEN_NAVBAR_CHILD "Ping-Pong"=GRAS_ex_ping.html
127 DOXYGEN_NAVBAR_CHILD "RPC"=GRAS_ex_mmrpc.html
128 DOXYGEN_NAVBAR_CHILD "Token Ring"=GRAS_ex_token.html
129 DOXYGEN_NAVBAR_CHILD "Timers"=GRAS_ex_timer.html
132 There is some more examples in the distribution, under the directory
133 <tt>examples/gras</tt>.
136 #####################################################################
137 ######################### EXTRA PAGES ##############################
138 #####################################################################
140 ---------------------------------------------------------------------
141 --------------------- main() generation -----------------------------
142 ---------------------------------------------------------------------
144 /** \page GRAS_main_generation main function
146 \section GRAS_maingen_toc Table of content
148 - \ref GRAS_maingen_intro
149 - \ref GRAS_maingen_script
150 - \ref GRAS_maingen_make
154 \section GRAS_maingen_intro What's the matter with main() functions in GRAS?
156 In simulation mode, all processes are run as thread of the same process
157 while they are real processes in the real life. Unfortunately, the main
158 function of a real process must be called <tt>main</tt> while this
159 function must not use this name for threads.
161 To deal with this, you should call the main function of your processes
162 with another name (usually, the process function such as client, server,
163 or such). Then GRAS can generate the wrapper functions adapted to the
164 real and simulated modes.
166 \section GRAS_maingen_script Generating the main()s automatically
168 This is done by the gras_stub_generator program, which gets installed on
169 <tt>make install</tt> (the source resides in the tools/gras/ directory).
170 Here is the calling syntax:
171 \verbatim gras_stub_generator <project_name> <deployment_file.xml>\endverbatim
173 It parses the deployment file, searching for all the kind of processes
174 you have in your project. It then generates the following C files:
175 - a <tt>_<project_name>_<process_kind>.c</tt> file for each process kind you
177 They are used to launch your project in real life. They
178 contain a main() in charge of initializing the GRAS infrastructure and
179 launching your code afterward.
180 - a <tt>_<project_name>_simulator.c</tt> file.\n
181 This file is suited to the simulation mode. It contains a main()
182 function initializing the simulator and launching your project within.
184 For this to work, the name of process described in your deployment file
185 should match the name of a function in your code, which prototype is for
186 example: \verbatim int client(int argc,char *argv[]);\endverbatim
188 Unfortunately, all this is still partially documented. I guess I ought
189 to improve this situation somehow. In the meanwhile, check the generated
190 code and maybe also the GRAS \ref GRAS_example, sorry.
192 \section GRAS_maingen_make Integration within an hand-made Makefile
194 The easiest to set it up is to add the following chunk at the end of
195 your Makefile (or Makefile.am), putting the right values into NAME and
197 \verbatim NAME=your_project_name
198 PROCESSES=list of processes type in your project
200 $(foreach proc, $(PROCESSES), _$(NAME)_$(proc).c) _$(NAME)_simulator.c: $(NAME).c $(NAME)_deployment.xml
201 path/to/gras_stub_generator $(NAME) $(NAME)_deployment.xml >/dev/null
204 Of course, your personal millage may vary. For the \ref GRAS_ex_ping, may read:
205 \verbatim _ping_client.c _ping_server.c _ping_simulator.c: ping.c ping_deployment.xml
206 $(top_srcdir)/tools/gras/gras_stub_generator ping ping_deployment.xml >/dev/null
210 Actually, gras_stub_generator also generates some makefiles both for
211 local compilation and remote code distribution and installation. See the
212 section \ref GRAS_compile for more details.
216 ---------------------------------------------------------------------
217 ------------------------- Compiling ---------------------------------
218 ---------------------------------------------------------------------
220 /** \page GRAS_compile Compiling your project
222 As explained in section \ref GRAS_main_generation, the
223 gras_stub_generator tool can be used to generate the system
224 initialization code in your projet. While we were at this, this tool
225 also generates the makefiles you will need to compile your project
228 Code source deployment and remote compilation also constitutes a
229 challenging area in distributed applications development. The GRASPE
230 (GRAS Platform Expender) tool was designed to make this less painful.
232 \section GRAS_compile_toc Table of content
234 - \ref GRAS_compile_local
235 - \ref GRAS_compile_local_install
236 - \ref GRAS_compile_local_helpfiles
237 - \ref GRAS_compile_local_makefile
238 - \ref GRAS_compile_remote
242 \section GRAS_compile_local Local compilation of GRAS projects
244 \subsection GRAS_compile_local_install Installing SimGrid and GRAS
246 To compile locally a GRAS project, you first need to install SimGrid on
247 your machine. Use the --prefix flag to the configure script to specify
248 where you want to install the toolkit (refere to section \ref
249 faq_compiling for more information)
251 \subsection GRAS_compile_local_helpfiles Simulation description files
253 Then, you will probably need to write a platform description file and
254 application deployment description file to feed the simulator with. This
255 part is unfortunatelly not documented enough. Files examples can be
256 found along with the MSG \ref MSG_ex_master_slave example.
258 \note yes, both platform and application description files are portable
259 between MSG and GRAS. Actually, there depend on the SURF, not on the
260 programming environment you use.
262 For the first try, you could probably reuse the provided platform file
263 as is while you will need to adapt the application file to fit your
266 To generate new platform files, we usually use the Tiers Topology
267 Generator (ask google about it) and annotate the generated graph with
268 home-made scripts to let them fit the SURF. Those scripts live in the
269 tools/platform_generation/ directory of the distribution.
271 \subsection GRAS_compile_local_makefile Generating a Makefile usable for your project
273 From the information contained in the application description file, the
274 gras_stub_generator tool can create a Makefile which can be used to
275 seamlessly compile your project. Just go to the directory containing all
276 your project files, and type:
278 \verbatim path/to/gras_stub_generator [project_name] [application_deployment.file] >/dev/null
281 The first argument is the name of your project, such as
282 "MyLovelyApplication" while the second one is the application deployment
285 Several files get generated by this command. One C file per kind of
286 process in your project (such as "master" and "slave") plus one C file
287 for simulating your project. All those files are (or should ;) described
288 in section \ref GRAS_main_generation.
290 The most intersting file in this context is
291 [project_name].Makefile.local (you can safely ignore the others for
292 now). To use it, simply type (from your project main directory):
294 \verbatim GRAS_ROOT=/path/to/simgrid/installation make -f [project_name].Makefile.local
297 And that's it, all the binaries are built and linked against the correct
300 \section GRAS_compile_remote Distribution and remote compilation of GRAS projects
302 Actually, there is two somehow parallel ways to do so since both Arnaud
303 and Martin gave it a try. Merging both approaches is underway. As usual,
304 if you want to help, you're welcome ;)
308 #####################################################################
309 ######################### EXAMPLES #################################
310 #####################################################################
312 ---------------------------------------------------------------------
313 ------------------------- Ping Pong ---------------------------------
314 ---------------------------------------------------------------------
316 /** \page GRAS_ex_ping The classical Ping-Pong in GRAS
318 This example implements the very classical ping-pong in GRAS. It
319 involves a client (initiating the ping-pong) and a server (answering to
322 It works the following way:
323 - Both the client and the server register all needed messages
324 - The server registers a callback to the ping message, which sends pong
326 - The client sends the ping message to the server, and waits for the
327 pong message as an answer.
329 This example resides in the <b>examples/gras/ping/ping.c</b> file. Yes, both
330 the code of the client and of the server is placed in the same file. See
331 the \ref GRAS_main_generation section if wondering.
333 \section GRAS_ex_ping_toc Table of contents of the ping example
334 - \ref GRAS_ex_ping_common
335 - \ref GRAS_ex_ping_initial
336 - \ref GRAS_ex_ping_register
337 - \ref GRAS_ex_ping_server
338 - \ref GRAS_ex_ping_serdata
339 - \ref GRAS_ex_ping_sercb
340 - \ref GRAS_ex_ping_sermain
341 - \ref GRAS_ex_ping_client
342 - \ref GRAS_ex_ping_climain
346 \dontinclude gras/ping/ping_common.c
348 \section GRAS_ex_ping_common 1) Common code to the client and the server
350 \subsection GRAS_ex_ping_initial 1.a) Initial settings
352 Let's first load the module header and declare a logging category (see
353 \ref XBT_log for more info on logging).
358 The module header <tt>ping.h</tt> reads:
360 \dontinclude gras/ping/ping.h
365 \subsection GRAS_ex_ping_register 1.b) Register the messages
367 This function, called by both the client and the server is in charge of
368 declaring the existing messages to GRAS. Since the payload does not
369 involve any newly created types but only int, this is quite easy.
370 (to exchange more complicated types, see \ref GRAS_dd or
371 \ref GRAS_ex_mmrpc for an example).
373 \dontinclude gras/ping/ping_common.c
374 \skip register_messages
377 [Back to \ref GRAS_ex_ping_toc]
379 \section GRAS_ex_ping_server 2) Server's code
381 \subsection GRAS_ex_ping_serdata 2.a) The server's globals
383 In order to ensure the communication between the "main" and the callback
384 of the server, we need to declare some globals. We have to put them in a
385 struct definition so that they can be handled properly in GRAS (see the
386 \ref GRAS_globals for more info).
388 \dontinclude gras/ping/ping_server.c
392 \subsection GRAS_ex_ping_sercb 2.b) The callback to the ping message
394 Here is the callback run when the server receives any ping message (this
395 will be registered later by the server).
397 \skip server_cb_ping_handler
398 \until end_of_server_cb_ping_handler
400 \subsection GRAS_ex_ping_sermain 2.c) The "main" of the server
402 This is the "main" of the server. As explained in the \ref
403 GRAS_main_generation, you must not write any main()
404 function yourself. Instead, you just have to write a regular function
405 like this one which will act as a main.
410 [Back to \ref GRAS_ex_ping_toc]
412 \section GRAS_ex_ping_client 3) Client's code
414 \subsection GRAS_ex_ping_climain 3.a) Client's "main" function
416 This function is quite straightforward, and the inlined comments should
417 be enough to understand it.
419 \dontinclude gras/ping/ping_client.c
423 [Back to \ref GRAS_ex_ping_toc]
426 ---------------------------------------------------------------------
427 --------------------- Simple Token Ring -----------------------------
428 ---------------------------------------------------------------------
430 /** \page GRAS_ex_token Token Ring example
432 This example implements the token ring algorithm. It involves several
433 nodes arranged in a ring (each of them have a left and a right neighbour)
434 and exchanging a "token". This algorithm is one of the solution to ensure
435 the mutual exclusion between distributed processes. There is only one
436 token at any time, so the process in its possession is ensured to be the
437 only one having it. So, if there is an action you want all processes to
438 do alternativly, but you cannot afford to have two processes doing it at
439 the same time, let the process having the token doing it.
441 Actually, there is a lot of different token ring algorithms in the
442 litterature, so this example implements one of them: the simplest one.
443 The ring is static (no new node can join it, and you'll get trouble if
444 one node dies or leaves), and nothing is done for the case in which the
447 - \ref GRAS_ex_stoken_deploy
448 - \ref GRAS_ex_stoken_global
449 - \ref GRAS_ex_stoken_callback
450 - \ref GRAS_ex_stoken_main
452 \section GRAS_ex_stoken_deploy 1) Deployment file
454 Here is the deployment file:
455 \include examples/gras/mutual_exclusion/simple_token/simple_token.xml
457 The neighbour of each node is given at startup as command line argument.
458 Moreover, one of the nodes is instructed by a specific argument (the one
459 on Tremblay here) to create the token at the begining of the algorithm.
461 \section GRAS_ex_stoken_global 2) Global definition
463 The token is incarned by a specific message, which circulates from node
464 to node (the payload is an integer incremented at each hop). So, the most
465 important part of the code is the message callback, which forwards the
466 message to the next node. That is why we have to store all variable in a
467 global, as explained in the \ref GRAS_globals section.
469 \dontinclude examples/gras/mutual_exclusion/simple_token/simple_token.c
473 \section GRAS_ex_stoken_callback 3) The callback
475 Even if this is the core of this algorithm, this function is quite
478 \skip node_cb_stoken_handler
479 \until end_of_node_cb_stoken_handler
481 \section GRAS_ex_stoken_main 4) The main function
483 This function is splited in two parts: The first one performs all the
484 needed initialisations (points 1-7) while the end (point 8. below) calls
485 gras_msg_handle() as long as the planned amount of ring loops are not
493 ---------------------------------------------------------------------
494 -------------------------- MM RPC -----------------------------------
495 ---------------------------------------------------------------------
497 /** \page GRAS_ex_mmrpc A simple RPC for matrix multiplication
499 This example implements a remote matrix multiplication. It involves a client
500 (creating the matrices and sending the multiplications requests) and a server
501 (computing the multiplication on client's behalf).
503 This example also constitutes a more advanced example of data description
504 mechanisms, since the message payload type is a bit more complicated than in
505 other examples such as the ping one (\ref GRAS_ex_ping).
507 It works the following way (not very different from the ping example):
508 - Both the client and the server register all needed messages and datatypes
509 - The server registers a callback to the "request" message, which computes
510 what needs to be and returns the result to the expeditor.
511 - The client creates two matrices, ask for their multiplication and check
514 This example resides in the <b>examples/gras/mmrpc/mmrpc.c</b> file. (See
515 the \ref GRAS_main_generation section if wondering why both the server
516 and the client live in the same source file)
518 \section GRAS_ex_mmrpc_toc Table of contents of the mmrpc example
519 - \ref GRAS_ex_mmrpc_common
520 - \ref GRAS_ex_mmrpc_header
521 - \ref GRAS_ex_mmrpc_dataregister
522 - \ref GRAS_ex_mmrpc_logdef
523 - \ref GRAS_ex_mmrpc_msgregister
524 - \ref GRAS_ex_mmrpc_matdump
525 - \ref GRAS_ex_mmrpc_server
526 - \ref GRAS_ex_mmrpc_serinc
527 - \ref GRAS_ex_mmrpc_sercb
528 - \ref GRAS_ex_mmrpc_sermain
529 - \ref GRAS_ex_mmrpc_client
530 - \ref GRAS_ex_mmrpc_cliinc
531 - \ref GRAS_ex_mmrpc_climain
536 \section GRAS_ex_mmrpc_common 1) Common code to the client and the server (mmrpc_common.c and mmrpc.h)
539 \subsection GRAS_ex_mmrpc_header 1.a) Module header (mmrpc.h)
541 This loads the gras header and declare the function's prototypes as well
544 \dontinclude gras/mmrpc/mmrpc.h
549 \subsection GRAS_ex_mmrpc_dataregister 1.b) Register the data types (mmrpc.h)
551 The messages involved in this example do use structures as payload,
552 so we have to declare it to GRAS. Hopefully, this can be done easily by enclosing
553 the structure declaration within a \ref GRAS_DEFINE_TYPE macro call. It will then copy this
554 declaration into an hidden string variable, which can be automatically parsed at
555 run time. Of course, the declaration is also copied unmodified by this macro, so that it
556 gets parsed by the compiler also.
558 There is some semantic that GRAS cannot guess alone and you need to <i>annotate</i>
559 your declaration to add some. For example, the ctn pointer can be a reference to an
560 object or a whole array (in which case you also has to specify its size). This is done
561 with the GRAS_ANNOTE call. It is removed from the text passed to the compiler, but it helps
562 GRAS getting some information about the semantic of your data. Here, it says that \a ctn is an
563 array, which size is the result of the operation \a rows * \a cols (with \a rows and \a cols
564 being the other fields of the structure).
566 Please note that this annotation mechanism is not as robust and cool as this example seems to
567 imply. If you want to use it yourself, you'd better use the exact right syntax, which is
568 detailed in the \ref GRAS_dd section.
570 \skip GRAS_DEFINE_TYPE
573 \subsection GRAS_ex_mmrpc_logdef 1.c) Logging category definition (mmrpc_common.c)
575 Let's first load the module header and declare a logging category (see
576 \ref XBT_log for more info on logging). This logging category does live
577 in this file (ie the required symbols are defined here and declared as
578 "extern" in any other file using them). That is why we use
579 \ref XBT_LOG_NEW_DEFAULT_CATEGORY here and
580 \ref XBT_LOG_EXTERNAL_DEFAULT_CATEGORY in mmrpc_client.c and mmrpc_server.c.
582 \dontinclude gras/mmrpc/mmrpc_common.c
586 \subsection GRAS_ex_mmrpc_msgregister 1.d) Register the messages (mmrpc_common.c)
588 This function, called by both the client and the server is in charge of
589 declaring the existing messages to GRAS. Note the use of the \ref gras_datadesc_by_symbol
590 function to parse and retrieve the structure declaration which were passed to \ref GRAS_DEFINE_TYPE
593 The datatype description builded that way can then be used to build an array datatype or
596 \skip register_messages
599 \subsection GRAS_ex_mmrpc_matdump 1.e) Helper debugging function (mmrpc_common.c)
601 This function dumps a matrix to screen for debugging.
607 [Back to \ref GRAS_ex_mmrpc_toc]
609 \section GRAS_ex_mmrpc_server 2) Server's code (mmrpc_server.c)
611 \subsection GRAS_ex_mmrpc_serinc 2.a) Server intial settings
613 All module symbols live in the mmrpc_common.c file. We thus have to
614 define \ref GRAS_DEFINE_TYPE_EXTERN to the preprocessor so that the
615 \ref GRAS_DEFINE_TYPE symbols don't get included here. Likewise, we use
616 \ref XBT_LOG_EXTERNAL_DEFAULT_CATEGORY to get the log category in here.
618 \dontinclude gras/mmrpc/mmrpc_server.c
622 \subsection GRAS_ex_mmrpc_sercb 2.b) The callback to the mmrpc message
624 Here is the callback run when the server receives any mmrpc message (this
625 will be registered later by the server). Note the way we get the message
626 payload. In the ping example, there was one additional level of pointer
627 indirection (see \ref GRAS_ex_ping_sercb). This is because the payload is
628 an array here (ie a pointer) whereas it is a scalar in the ping example.
630 \skip server_cb_request_handler
631 \until end_of_server_cb_request_handler
633 \subsection GRAS_ex_mmrpc_sermain 2.c) The "main" of the server
635 This is the "main" of the server. As explained in the \ref
636 GRAS_main_generation, you must not write any main()
637 function yourself. Instead, you just have to write a regular function
638 like this one which will act as a main.
643 [Back to \ref GRAS_ex_mmrpc_toc]
645 \section GRAS_ex_mmrpc_client 3) Client's code (mmrpc_client.c)
647 \subsection GRAS_ex_mmrpc_cliinc 2.a) Server intial settings
649 As for the server, some extra love is needed to make sure that automatic
650 datatype parsing and log categories do work even if we are using several
653 \dontinclude gras/mmrpc/mmrpc_client.c
657 \subsection GRAS_ex_mmrpc_climain 3.b) Client's "main" function
659 This function is quite straightforward, and the inlined comments should
660 be enough to understand it.
662 \dontinclude gras/mmrpc/mmrpc_client.c
666 [Back to \ref GRAS_ex_mmrpc_toc]
669 ---------------------------------------------------------------------
670 ---------------------------- Timers ---------------------------------
671 ---------------------------------------------------------------------
673 /** \page GRAS_ex_timer Some timer games
675 This example fools around with the GRAS timers (\ref GRAS_timer). It is
676 mainly a regression test, since it uses almost all timer features.
678 The main program registers a repetititive task and a delayed one, and
679 then loops until the <tt>still_to_do</tt> variables of its globals reach
680 0. The delayed task set it to 5, and the repetititive one decrease it
681 each time. Here is an example of output:
682 \verbatim Initialize GRAS
684 [1108335471] Programming the repetitive_action with a frequency of 1.000000 sec
685 [1108335471] Programming the delayed_action for after 2.000000 sec
686 [1108335471] Have a rest
687 [1108335472] Canceling the delayed_action.
688 [1108335472] Re-programming the delayed_action for after 2.000000 sec
689 [1108335472] Repetitive_action has nothing to do yet
690 [1108335473] Repetitive_action has nothing to do yet
691 [1108335473] delayed_action setting globals->still_to_do to 5
692 [1108335474] repetitive_action decrementing globals->still_to_do. New value: 4
693 [1108335475] repetitive_action decrementing globals->still_to_do. New value: 3
694 [1108335476] repetitive_action decrementing globals->still_to_do. New value: 2
695 [1108335477] repetitive_action decrementing globals->still_to_do. New value: 1
696 [1108335478] repetitive_action decrementing globals->still_to_do. New value: 0
697 Exiting GRAS\endverbatim
700 - \ref GRAS_ex_timer_decl
701 - \ref GRAS_ex_timer_delay
702 - \ref GRAS_ex_timer_repeat
703 - \ref GRAS_ex_timer_main
707 \section GRAS_ex_timer_decl 1. Declarations and headers
711 \section GRAS_ex_timer_delay 2. Source code of the delayed action
712 \skip repetitive_action
713 \until end_of_repetitive_action
715 \section GRAS_ex_timer_repeat 3. Source code of the repetitive action
717 \until end_of_delayed_action
719 \section GRAS_ex_timer_main 4. Source code of main function