/usr/share/doc/simgrid/html/community.html is in simgrid-doc 3.14.159-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<title>SimGrid: The SimGrid Community</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="navtree.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="resize.js"></script>
<script type="text/javascript" src="navtreedata.js"></script>
<script type="text/javascript" src="navtree.js"></script>
<script type="text/javascript">
$(document).ready(initResizable);
</script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<script type="text/javascript">
$(document).ready(function() { init_search(); });
</script>
<script type="text/x-mathjax-config">
MathJax.Hub.Config({
extensions: ["tex2jax.js"],
jax: ["input/TeX","output/HTML-CSS"],
});
</script><script type="text/javascript" src="/usr/share/javascript/mathjax/MathJax.js/MathJax.js"></script>
<link href="stylesheet.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">SimGrid
 <span id="projectnumber">3.14.159</span>
</div>
<div id="projectbrief">Versatile Simulation of Distributed Systems</div>
</td>
</tr>
</tbody>
</table>
</div>
<div id="navrow1" class="tabs">
<ul class="tablist">
<li><a href="http://simgrid.gforge.inria.fr/"><span>Home page</span></a></li>
<li><a href="http://simgrid.gforge.inria.fr/documentation.html"><span>Online documentation</span></a></li>
<li><a href="javadoc"><span>Java documentation</span></a></li>
<li><a href="https://gforge.inria.fr/projects/simgrid"><span>Dev's Corner</span></a></li>
<li> <div id="MSearchBox" class="MSearchBoxInactive">
<span class="left">
<img id="MSearchSelect" src="search/mag_sel.png"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
alt=""/>
<input type="text" id="MSearchField" value="Search" accesskey="S"
onfocus="searchBox.OnSearchFieldFocus(true)"
onblur="searchBox.OnSearchFieldFocus(false)"
onkeyup="searchBox.OnSearchFieldChange(event)"/>
</span><span class="right">
<a id="MSearchClose" href="javascript:searchBox.CloseResultsWindow()"><img id="MSearchCloseImg" border="0" src="search/close.png" alt=""/></a>
</span>
</div>
</li>
</ul>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.13 -->
<script type="text/javascript">
var searchBox = new SearchBox("searchBox", "search",false,'Search');
</script>
</div><!-- top -->
<div id="side-nav" class="ui-resizable side-nav-resizable">
<div id="nav-tree">
<div id="nav-tree-contents">
<div id="nav-sync" class="sync"></div>
</div>
</div>
<div id="splitbar" style="-moz-user-select:none;"
class="ui-resizable-handle">
</div>
</div>
<script type="text/javascript">
$(document).ready(function(){initNavTree('community.html','');});
</script>
<div id="doc-content">
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
onkeydown="return searchBox.OnSearchSelectKey(event)">
</div>
<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0"
name="MSearchResults" id="MSearchResults">
</iframe>
</div>
<div class="header">
<div class="headertitle">
<div class="title">The SimGrid Community </div> </div>
</div><!--header-->
<div class="contents">
<div class="toc"><h3>Table of Contents</h3>
<ul><li class="level1"><a href="#community_contact">Contacting the community</a></li>
<li class="level1"><a href="#community_giveback">Giving back to SimGrid</a><ul><li class="level2"><a href="#contributing_spread">Spread the word</a></li>
<li class="level2"><a href="#contributing_bugs">Reporting (and fixing) any issue you find</a></li>
</ul>
</li>
<li class="level1"><a href="#community_extend">Extending SimGrid and its Ecosystem</a><ul><li class="level2"><a href="#contributing_contrib">Contributing features and associated tools</a></li>
<li class="level2"><a href="#contributing_todo">Possible Enhancements</a><ul><li class="level3"><a href="#contributing_todo_cxxification">Migration to C++</a></li>
<li class="level3"><a href="#contributing_todo_smpi">SMPI</a></li>
<li class="level3"><a href="#contributing_todo_mc">Model-checker</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</div>
<div class="textblock"><p>SimGrid is a free software, written by a community of people.</p>
<p>It started as a little software to help ourselves in our own research, and as more people put their input into the pot, it turned into something that we hope to be valuable to many people. So yes. We hope that SimGrid is helping you doing what you want, and that you will join our community of happy simgriders.</p>
<h1><a class="anchor" id="community_contact"></a>
Contacting the community</h1>
<p>There are several locations where you can connect and discuss about SimGrid. If you have a question, please have a look at the documentation and examples first, but if some remain don't hesitate to ask the community for help. If you do not have a question, just come to us and say hello! We love earing about how people use SimGrid.</p>
<ul>
<li>For questions or remarks, drop us an email on the <a href="#" onclick="location.href='mai'+'lto:'+'sim'+'gr'+'id-'+'us'+'er@'+'li'+'sts'+'.g'+'for'+'ge'+'.in'+'ri'+'a.f'+'r'; return false;">User Mailing list</a> (to subscribe, visit the <a href="http://lists.gforge.inria.fr/mailman/listinfo/simgrid-user">webinterface</a>); you can also check out <a href="http://lists.gforge.inria.fr/pipermail/simgrid-user/">our archives</a>. We prefer you to <b>not use private emails</b>. SimGrid is an open framework, and you never know who have the time and knowledge to answer your question, so please keep messages on the public mailing list.</li>
<li>Join us on IRC and ask your question directly on the channel #simgrid at <b>irc.debian.org</b>. Be warned that even if many people are connected to the chanel, they may not be staring at their IRC windows. So don't be surprised if you don't get an answer in the second, and turn to the mailing lists if nobody seems to be there.</li>
<li>Asking your question on <a href="http://stackoverflow.com/questions/tagged/simgrid">StackOverflow</a> is also a good idea, as this site is very well indexed. We answer questions there too (don't forget to use the SimGrid tag in your question so that we can see it), and they remain usable for the next users.</li>
</ul>
<h1><a class="anchor" id="community_giveback"></a>
Giving back to SimGrid</h1>
<p>We are sometimes asked by users how to give back to the project. Here are some ideas, but if you have new ones, feel free to share them with us.</p>
<h2><a class="anchor" id="contributing_spread"></a>
Spread the word</h2>
<p>There are many ways to help the SimGrid project. The first and most natural one is to <b>use it for your research, and say so</b>. Cite the SimGrid framework in your papers and discuss of its advantages with your colleagues to spread the word. When we ask for new fundings to sustain the project, the amount of publications enabled by SimGrid is always the first question we get. The more you use the framework, the better for us.</p>
<p>Make sure that your scientific publications using SimGrid actually cite the <a href="http://simgrid.gforge.inria.fr/Publications.html">right paper</a>. Also make sure that these citations are correctly listed on <a href="http://simgrid.gforge.inria.fr/Usages.html">our list</a>.</p>
<p>You can also <b>help us constituting an active and welcoming user community</b>. Subscribe to the mailing lists, and answer the questions that newscomers have if you can. Point them (gently ;) to the relevant part of the documentation on need, and help them becoming part of our community too.</p>
<p>Another easy way to help the project is to add a link to the <a href="http://simgrid.gforge.inria.fr">SimGrid homepage</a> on your site to <b>improve SimGrid's ranking in search engines</b>.</p>
<p>Finally, if you organize a scientific event where you expect many potential users, <b>you can invite us to give a tutorial on SimGrid</b>. We found that 45 minutes to one hour is very sharp, but doable. It allows us to explain the main motivations and outcomes of the project in order to motivate the attendees get more information on SimGrid, and eventually improve their scientific habits by using a sound simulation framework. <a href="http://people.irisa.fr/Martin.Quinson/blog/2012/1120/Simgrid_at_Louvain/">Here</a> is an example of such a presentation.</p>
<h2><a class="anchor" id="contributing_bugs"></a>
Reporting (and fixing) any issue you find</h2>
<p>Because of its size and complexity, SimGrid is not perfect and contains a large amount of glitches and issues. When you find one, don't assume that it's here because we don't care. It survived only because nobody told us. We unfortunately cannot endlessly review our large code and documentation base. So please, <b>report any issue you find</b>, be it a typo in the documentation, a paragraph that needs to be reworded, a bug in the code, or any other problem. The best way to do so is to open an issue on our GitHub's <a href="https://github.com/simgrid/simgrid/issues">Bug Tracker</a> so that we don't forget about it (if you want to put some attachment, you can use <a <a href="https://gforge.inria.fr/tracker/?atid=165&group_id=12&func=browse">https://gforge.inria.fr/tracker/?atid=165&group_id=12&func=browse</a>">this other bugtracker instead).</p>
<p>The worst way to report such issues is to go through private emails. These are unreliable, and we are trying to develop SimGrid openly, so private discussions are to be avoided if possible.</p>
<p>If you can provide a patch fixing the issue you report, that's even better. If you cannot, then you need to give us a minimal working example (MWE), that is a ready to use solution that reproduces the problem you face. Your bug will take much more time for us to reproduce and fix if you don't give us the MWE, so you want to help us helping you to get things efficient.</p>
<p>Of course, a very good way to give back to the SimGrid community is to <b>triage and fix the bugs in the Bug Tracking Systems</b>. If you can come up with a patch fixing them, we will be more than happy to apply your changes so that the whole community enjoys them.</p>
<h1><a class="anchor" id="community_extend"></a>
Extending SimGrid and its Ecosystem</h1>
<h2><a class="anchor" id="contributing_contrib"></a>
Contributing features and associated tools</h2>
<p>If you deeply miss a feature in the framework, you should consider implementing it yourself. SimGrid is free software, meaning that you are free to help yourself. Of course, we'll do our best to assist you in this task, so don't hesitate to contact us with your idea.</p>
<p>You could write a new plugin extending SimGrid in some way, or a routing model for another kind of network. But even if you write your own platform file, this is probably interesting to other users too, and could be included to SimGrid. Modeling accurately a given platform is a difficult work, which outcome is very precious to us.</p>
<p>Or maybe you developed an independent tool on top of SimGrid. We'd love helping you gaining visibility by listing it in our <a href="http://simgrid.gforge.inria.fr/contrib.html">Contrib section</a>.</p>
<h2><a class="anchor" id="contributing_todo"></a>
Possible Enhancements</h2>
<p>If you want to start working on the SimGrid codebase, here are a few ideas of things that could be done to improve the current code (not all of them are difficult, do trust yourself ;)</p>
<h3><a class="anchor" id="contributing_todo_cxxification"></a>
Migration to C++</h3>
<p>The code is being migrated to C++ but a large part is still C (or C++ with C idioms). It would be valuable to replace C idioms with C++ ones:</p>
<ul>
<li>replace XBT structures and C dynamic arrays with C++ containers;</li>
<li>replace <code>char*</code> strings with <code>std::string</code>;</li>
<li>use exception-safe RAII (<code>std::unique_ptr</code>, etc.) instead of explicit <code>malloc/free</code> or <code>new/delete</code>;</li>
<li>use <code>std::function</code> (or template functionoid arguments) instead of function pointers;</li>
</ul>
<h4>Exceptions</h4>
<p>SimGrid used to implement exceptions in C. This has been replaced with C++ exceptions but some bits of the C exceptions are still remaining:</p>
<ul>
<li><code><a class="el" href="structxbt__ex.html" title="A legacy exception. ">xbt_ex</a></code> was the type of C exceptions. It is now a standard C++ exception. We might want to remove this exception and use a more idiomatic C++ solution with dedicated exception classes for different errors. <code>std::system_error</code> might be used as well by replacing some <code>xbt_errcat_t</code> with custom subclasses of <code>std::error_category</code>.</li>
<li>The C API currently throws exceptions. Throwing exceptions out of a C API is not very friendly. C code does not expect them, cannot catch them and cannot handle resource management properly in face of exceptions. We should clearly separate the C++ API and the C API and catch all exceptions before they get ouf of C APIs.</li>
</ul>
<h4>Time and duration</h4>
<p>Some support for C++11-style time/duration is implemented (see <code><a class="el" href="chrono_8hpp.html" title="Time support. ">chrono.hpp</a></code>) but only available in some (S4U) APIs. It would be nice to add support for them in the rest of the C++ code.</p>
<p>A related change would be to avoid using "-1" to mean "forever" at least in S4U and in the internal code. For compatibility, MSG should probably keep this semantic. We should probably always use separate functions (<code>wait</code> vs <code>wait_for</code>).</p>
<h4>Futures and Promises</h4>
<ul>
<li>Some features are missing in the Maestro future implementation (<code><a class="el" href="classsimgrid_1_1kernel_1_1Future.html" title="Result of some (probably) asynchronous operation in the SimGrid kernel. ">simgrid::kernel::Future</a></code>, <code><a class="el" href="classsimgrid_1_1kernel_1_1Promise.html" title="Producer side of a simgrid::kernel::Future. ">simgrid::kernel::Promise</a></code>) could be extended to support additional features: <code>when_any</code>, <code>shared_future</code>, etc.</li>
<li>The corresponding feature might then be implemented in the user process futures (<code><a class="el" href="classsimgrid_1_1simix_1_1Future.html" title="A blocking (wait()-based) future for SIMIX processes. ">simgrid::simix::Future</a></code>).</li>
<li>Currently <code>.then()</code> is not available for user futures. We would need to add a basic user event loop in order to queue the pending continuations.</li>
<li>We might need to provide an option to cancel a pending operation. This might be achieved by defining some <code>Action</code> or <code>Operation</code> class with an API compatible with <code>Future</code> (and convertible to it) but with an additional <code>.cancel()</code> method.</li>
</ul>
<h3><a class="anchor" id="contributing_todo_smpi"></a>
SMPI</h3>
<h4>Process-based privatization</h4>
<p>Currently, all the simulated processes live in the same process as the SimGrid simulator. The benefit is that we don't have to do context switches and IPC between the simulator and the processes.</p>
<p>The fact that they share the same address space means that one memory corruption in one simulated process can propagate to the other ones and to the SimGrid simulator itself.</p>
<p>Moreover, the current design for SMPI applications is to compile the MPI code normally and execute it once per simulated process in the same system process: This means that all the existing simulated MPI processes share the same virtual address space and share by default the same global variables. This is not correct as each MPI process is expected to use its own address space and have its own global variables. In order to fix, this problem we have an optional SMPI privatization feature which creates an instanciation of the executable data segment per MPI process and map the correct one (using <code>mmap</code>) at each context switch.</p>
<p>This approach has many problems:</p>
<ol type="1">
<li>It is not completely safe. We only handle SMPI privatization for the global variables in the execute data segment. Shared objects are ignored but some may contain global variables which may need to be privatized:<ul>
<li>libsimgrid for example must not be privatized because it contains shared state for the simulator;</li>
<li>libc must not be privatized for the same reason (but some global variables in the libc may not be privatized);</li>
<li>if we use global variables of some shared object in the executable, this global variable will be instanciated in the executable (because of copy relocation) and will be privatized even if it shoud not.</li>
</ul>
</li>
<li>We cannot execute the MPI processes in parallel. Only one can execute at the same time because only one privatization segment can be mapped at a given time.</li>
</ol>
<p>In order to fix this, the standard solution is to move each MPI process in its own system process and use IPC to communicate with the simulator. One concern would be the impact on performance and memory consumption:</p>
<ul>
<li>It would introduce a lot of context switches and IPC communications between the MPI processes and the SimGrid simulator. However, currently every context switch needs a <code>mmap</code> for SMPI privatization which is costly as well (TLB flush).</li>
<li>Instanciating a lot of processes might consume more memory which might be a problem if we want to simulate a lot of MPI processes. Compiling MPI programs as static executables with a lightweight libc might help and we might want to support that. The SMPI processes should probably not embed all the SimGrid simulator and its dependencies, the C++ runtime, etc.</li>
</ul>
<p>We would need to modify the model-checker as well which currently can only manage on model-checked process. For the model-checker we can expect some benefits from this approach: if a process did not execute, we know its state did not change and we don't need to take its snapshot and compare its state.</p>
<p>Other solutions for this might include:</p>
<ul>
<li>Mapping each MPI process in the process of the simulator but in a different symbol namespace (see <code>dlmopen</code>). Each process would have its own separate instanciation and would not share libraries.</li>
<li>Instanciate each MPI process in a separate lightweight VM (for example based on WebAssembly) in the simualtor process.</li>
</ul>
<h3><a class="anchor" id="contributing_todo_mc"></a>
Model-checker</h3>
<h4>Overhaul the state comparison code</h4>
<p>The state comparison code is quite complicated. It has very long functions and is programmed mostly using C idioms and is difficult to understand and debug. It is in need of an overhaul:</p>
<ul>
<li>cleanup, refactoring, usage of C++ features.</li>
<li>The state comparison code works by infering types of blocks allocated on the heap by following pointers from known roots (global variables, local variables). Usually the first type found for a given block is used even if a better one could be found later. By using a first pass of type inference, on each snapshot before comparing the states, we might use a better type information on the different blocks.</li>
<li>We might benefit from adding logic for handling some known types. For example, both <code>std::string</code> and <code>std::vector</code> have a capacity which might be larger than the current size of the container. We should ignore the corresponding elements when comparing the states and infering the types.</li>
<li>Another difficulty in the state comparison code is the detection of dangling pointers. We cannot easily know if a pointer is dangling and dangling pointers might lead us to choose the wrong type when infering heap blocks. We might mitigate this problem by delaying the reallocation of a freed block until there is no blocks pointing to it anymore using some sort of basic garbage-collector.</li>
</ul>
<h4>Hashing the states</h4>
<p>In order to speed up the state comparison an idea was to create a hash of the state. Only states with the same hash would need to be compared using the state comparison algorithm. Some information should not be inclueded in the hash in order to avoid considering different states which would otherwise would have been considered equal.</p>
<p>The states could be indexed by their hash. Currently they are indexed by the number of processes and the amount of heap currently allocated (see <code>DerefAndCompareByNbProcessesAndUsedHeap</code>).</p>
<p>Good candidate informations for the state hashing:</p>
<ul>
<li>number of processes;</li>
<li>their backtraces (instruction addresses);</li>
<li>their current simcall numbers;</li>
<li>some simcall arguments (eg. number of elements in a waitany);</li>
<li>number of pending communications;</li>
<li>etc.</li>
</ul>
<p>Some basic infrastructure for this is already in the code (see <code>mc_hash.cpp</code>) but it is currently disabled.</p>
<h4>Separate the model-checker code from libsimgrid</h4>
<h4>Interface with the model-checked processes</h4>
<p>The model-checker reads many information about the model-checked process by <code>process_vm_readv()</code>-ing brutally the data structure of the model-checked process leading to some horrible code such as walking a swag from another process. It prevents us as well from replacing some XBT data structures with standard C++ ones. We need a sane way to expose the relevant information to the model-checker.</p>
<h4>Generic simcalls</h4>
<p>We have introduced some generic simcalls which can be used to execute a callback in SimGrid Maestro context. It makes it a lot easier to interface the simulated process with the maestro. However, the callbacks for the model-checker which cannot decide how it should handle them. We would need a solution for this if we want to be able to replace the simcalls the model-checker cares about by generic simcalls.</p>
<h4>Defining an API for writing Model-Checking algorithms</h4>
<p>Currently, writing a new model-checking algorithms in SimGridMC is quite difficult: the logic of the model-checking algorithm is mixed with a lot of low-level concerns about the way the model-checker is implemented. This makes it difficult to write new algorithms and difficult to understand, debug, and modify the existing ones. We need a clean API to express the model-checking algorithms in a form which is closer to the text-book/paper description. This API must be exposed in a a language which is more adequate to this task.</p>
<p>Tasks:</p>
<ol type="1">
<li>Design and implement a clean API to express model-checking algorithms. A <code>Session</code> class currently exists for this but is not feature complete and should probably be rewritten. It should be easy to create bindings for different languages on top of this API.</li>
<li>Create a binding to some better suited, dynamic, scripting language (e.g., Lua).</li>
<li>Rewrite the existing model-checking algorithms in this language using the new API. </li>
</ol>
</div></div><!-- contents -->
</div><!-- doc-content -->
<!-- start footer part -->
<div id="nav-path" class="navpath"><!-- id is needed for treeview function! -->
<ul>
<li class="footer">Generated by
<a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/></a> 1.8.13 </li>
</ul>
</div>
</body>
</html>
|