<div dir="ltr"><div><div>Hi <span style class="">Judwig</span>,<br><br> To be honest with you, I am not even worried about the performance problems linked to the thread/process trade-off. Even though we, yes, that may play a significant role.<br>

<br>My point is more in terms of "easy to implement", ideally, if RIOT wasn't dependent on any <span style class="">globals</span> we could model the riot nodes as objects in a C++ framework, and all the iteration among nodes could be as simple as function calls. However, to minimize changes, the second easiest way would be to have all the nodes modeled as threads. The advantage is that we can get rid of the biggest hassle we have with process that is manipulating the shared memory area.  Other advantage is that the debugging process is somehow simpler.  <br>

<br>It is not MANDATORY, I was just curious. (OK, yes, you can say I am lazy, and that is true :)... but It is more polite to say.... I would like to accomplish my task, with the minimum effort possible. I guess we can say it is an "optimization"  problem to where we want to minimize effort. :)<br>

<br>However, what you said kind of scared me a little, what is the  <span style class="">MTBF</span> of Riot? If crashing is more or less expected... then your concern is more than justifiable and process is maybe the way to go.  Even though in a simulation, if a machine crashes, and it wasn't expected.... that may pollute the results and the simulation should be aborted anyway.... well at least a BIG warning should be raised.... unless it is the homework of networks 101, in that case.... no one cares. <br>

<br></div>   Best regards...<br><br></div>           Daniel<br><div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 27, 2014 at 1:56 PM, Ludwig Ortmann <span dir="ltr"><<a href="mailto:ludwig.ortmann@fu-berlin.de" target="_blank">ludwig.ortmann@fu-berlin.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Daniel & all,<br>
<div class=""><br>
On Thu, Feb 20, 2014 at 06:05:54PM +0100, Emmanuel Baccelli wrote:<br>
> Daniel Camara from the ns3 team (in cc) asked me a question that I thought<br>
> I'd better relay here to gather the most informed opinions:<br>
><br>
> "Is there any conceivable way for all global variables in RIOT to be<br>
> declared as thread local? If this could be done adaptation with ns-3 would<br>
> be MUCH easier."<br>
><br>
> Any opinion on this question? Or on how to better formulate the question?<br>
<br>
</div>It would be possible to extend all of RIOTs global variables with a macro<br>
like RIOTGLOBAL and have that expand to _thread for a ns3 port. Not<br>
really nice, but we could do that.<br>
<br>
What I don't really see is the performance gain. Maybe you can shed<br>
some light here.<br>
Thread-local storage requires the threading library to update all<br>
global variables and the context on every thread switch. Not using<br>
threads on the other hand would require the system scheduler to update<br>
the context. To me it appears that there is overhead involved in both<br>
possibilities that probably cancel each other out.<br>
<br>
Using processes instead of threads has the benefit of separated<br>
address spaces though. That means that memory errors in RIOT would not<br>
lead to the whole simulation crashing.<br>
<br>
Furthermore I suspect running RIOT as a thread might lead to conflicts<br>
with RIOTs own pthread implementation.. maybe someone from that domain<br>
can say something about this.<br>
<br>
Cheers, Ludwig<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@riot-os.org">devel@riot-os.org</a><br>
<a href="http://lists.riot-os.org/mailman/listinfo/devel" target="_blank">http://lists.riot-os.org/mailman/listinfo/devel</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>    Best regards... <br>            <br>                     Daniel<br>
</div>