GRAS

Realistic programming environment (Grid Reality And Simulation) More...

Modules
	Communication facilities
	Virtualization

Functions
void	gras_init (int *argc, char **argv)
	Initialize the gras mechanisms.
void	gras_exit (void)
	Finalize the gras mechanisms.

Detailed Description

Realistic programming environment (Grid Reality And Simulation)

GRAS provides a complete API to implement distributed application on top of heterogeneous plateforms. In addition to the SimGrid implementation of this interface (allowing you to work on your application within the comfort of the simulator), an implementation suited to real platforms is also provided (allowing you to really use your application once you're done with developing it). It may still contain rought corners as GRAS is not the most used part of SimGrid, however.

GRAS thus constitute a complete grid application developement framework, encompassing both developer helping tools (the simulator and associated tools) and an efficient while portable execution runtime.

Who should use this (and who shouldn't)

You should use this programming environment if you want to develop real applications, ie if the final result of your work is a program which may eventually be distributed. Rember however that GRAS is considered as experimental at this point. Help would be welcomed to improve this sorry situation...

If you just want to study some heuristics for a given problem you don't want to implement really (ie, if your result would be a theorem), have a look at the MSG one, or the SimDag one if you need to use DAGs. If you want to study an existing MPI program, have a look at the SMPI one. If none of those programming environments fits your needs, you may consider implementing your own directly on top of SURF (but you probably want to contact us before).

GRAS offers the following functionnalities

• Communication facilities: Exchanging messages between peers
  • Data description : any data which may transit on the network must be described beforehand so that GRAS can handle the platform heterogeneity and convert them if needed.
  • Sockets : this is how to open a communication channel to other processes, and retrive information about them.
  • Messages : communications are message oriented. You have to describe all possible messages and their payload beforehand, and can then attach callbacks to the arrival of a given kind of message.
  • Timers : this is how to program repetitive and delayed tasks, not unlike cron(8) and at(1). This cannot be used to timeout a function (like setitimer(2) or signal(2) games could do).
• Virtualization: Running both on top of the simulator and on top of real platforms, and portability support.
  • Syscalls : You naturally don't want to call the gettimeofday(2) function in simulation mode since it would give you the time on the host running the simulation, not the time in the simulated world (you are belonging to).
    This a system call virtualization layer, which also acts as a portability layer.
  • Globals : The use of globals is forbidden since the "processes" are threads in simulation mode.
    This is how to let GRAS handle your globals properly.
  • Emulation support : Support to emulate code excution (ie, reporting execution time into the simulator and having code sections specific to simulation or to real mode).