[riot-devel] ns3 question about global variable in RIOT
ludwig.ortmann at fu-berlin.de
Thu Feb 27 17:28:46 CET 2014
On Thu, Feb 27, 2014 at 04:38:37PM +0100, Daniel Camara wrote:
> 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
I have trouble imagining how that would work - even without global
variables. RIOT has a preemptive scheduler and busy loops. That is:
RIOT threads can depend on preemption.
> 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. :)
OK then - like I said - it is possible.
I think the bigger question is about the feasibility regarding
threading implementation conflicts. (Anyone willing to contribute some
insight on the possibility of running RIOT inside a pthread here?)
> However, what you said kind of scared me a little, what is the MTBF of
That depends on how fresh the code is.
I mean - the network stack for example is under heavy development at the
moment and during a phase like that unchecked NULL pointers seem to
slip through every once in a while. Of course we will get to a point
where the stack is in sane state, but I assume one might want to use
the simulator to verify some implementation aspects during
> 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.
Of course, the results will be spoilt. But I don't know ns3 - if it's
no big deal if it crashes that's fine with me as well. If it can cause
damage (e.g. by corrupting files one might still want to have used
afterwards) that might be an argument for separate processes.
More information about the devel