[riot-devel] ns3 question about global variable in RIOT

Daniel Camara danielcamara at gmail.com
Thu Feb 27 16:38:37 CET 2014

Hi Judwig,

 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.

My point is more in terms of "easy to implement", ideally, if RIOT wasn't
dependent on any globals 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

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. :)

However, what you said kind of scared me a little, what is the  MTBF 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.

   Best regards...


On Thu, Feb 27, 2014 at 1:56 PM, Ludwig Ortmann <ludwig.ortmann at fu-berlin.de
> wrote:

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

    Best regards...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20140227/94a7ee52/attachment.html>

More information about the devel mailing list