Benjamin, I have not experienced a timer firing issue but I don't think I have a similar use case. If possible, can you reproduce the issue with a simple plugin based off of the bypass layer example and send it to the list along with a filled out PRF (source - emane/PROBLEM-REPORT-FORM).
When a scheduled event goes off, the processTimedEvent method is pushed on to the NEM layer's functor queue for processing. All of the process...() family of calls are executed that way using the NEM layer's dedicated single worker thread. Did you make your concurrent observation based on the thread id that was executing processTimedEvent? -- Steven Galgano Adjacent Link LLC On 11/22/2013 04:32 PM, Hamilton, Benjamin - 0665 - MITLL wrote: > Hello, > > > > I was trying to implement a MAC layer in EMANE 0.8.1 that relies on the > EMANE platform's scheduleTimedEvent / p executes concurrently with processDownstreamPacket for the same layer on the same NEM (apparently in separate threads). This doesn't occur that often, but I have seen it once or twice. This may be by design, but I didn't see this documented anywhere and it means I will probably need to lock my internal data structures before operating on them in either function. Also, if this is the case, are there any MAC layer functions that can be considered mutually exclusive, or will they all need to be locked?rocessTimedEvent functions and I've > been seeing some strange issues. I've put in some logging statements on > every time scheduledTimedEvent is called and at the top of processTimedEvent > for my layer, so the logging output looks something like: > > 16:11:01.789233 ERROR 1385154661.789233 [Node 3] Schedule Event 22 type=2 > time=1385154661.790210 > > 16:11:01.789251 ERROR 1385154661.789251 [Node 1] Schedule Event 23 type=2 > time=1385154661.790236 > > 16:11:01.790366 ERROR 1385154661.790365 [Node 2] Processing event 21, task 2 > > 16:11:01.790416 ERROR 1385154661.790415 [Node 1] Processing event 23, task 2 > > 16:11:01.790434 ERROR 1385154661.790434 [Node 2] Schedule Event 24 type=2 > time=1385154661.791400 > > 16:11:01.790448 ERROR 1385154661.790448 [Node 1] Schedule Event 25 type=2 > time=1385154661.791439 > > 16:11:01.790491 ERROR 1385154661.790490 [Node 3] Processing event 22, task 2 > > 16:11:01.790537 ERROR 1385154661.790537 [Node 3] Schedule Event 26 type=2 > time=1385154661.791514 > > 16:11:01.791670 ERROR 1385154661.791668 [Node 2] Processing event 24, task 2 > > 16:11:01.791685 ERROR 1385154661.791684 [Node 1] Processing event 25, task 2 > > 16:11:01.791700 ERROR 1385154661.791699 [Node 3] Processing event 26, task 2 > > 16:11:01.791723 ERROR 1385154661.791722 [Node 2] Schedule Event 27 type=2 > time=1385154661.792695 > > 16:11:01.791761 ERROR 1385154661.791760 [Node 3] Schedule Event 28 type=2 > time=1385154661.792723 > > 16:11:01.791836 ERROR 1385154661.791835 [Node 1] Schedule Event 29 type=2 > time=1385154661.792706 > > 16:11:01.791843 ERROR 1385154661.791843 [Node 4] Schedule Event 30 type=1 > time=1385154661.982612 > > This way I can track every event being scheduled and processed. > > > > 1. scheduleTimedEvent sometimes returns valid event ids (event id >= > 0), but the corresponding processTimedEvent is never called. I can see this > by searching the log file (grep -e Processing\ event\ 23, -e Schedule\ > Event\ 23\ ) and looking for adjacent lines that both have Schedule\ Event. > For example, looking at the trace for all events with event id=23 (grep -e > Processing\ event\ 23, -e Schedule\ Event\ 23\ ), I see something like: > > 16:11:08.629768 ERROR 1385154668.629767 [Node 1] Processing event 23, task 1 > > 16:11:08.629985 ERROR 1385154668.629985 [Node > 1][DEBUG][AthenaSupportEmane.cpp:487] Schedule Event 23 type=0 > time=1385154668.630342 > > 16:11:08.685817 ERROR 1385154668.685817 [Node > 3][DEBUG][AthenaSupportEmane.cpp:487] Schedule Event 23 type=2 > time=1385154668.686771 > > 16:11:08.687744 ERROR 1385154668.687743 [Node 3] Processing event 23, task 2 > > 16:11:08.741827 ERROR 1385154668.741826 [Node > 3][DEBUG][AthenaSupportEmane.cpp:487] Schedule Event 23 type=2 > time=1385154668.742777 > > I can verify that the events not processed in the log are not actually > processed since their side effects (such as scheduling more events or > transmitting packets) also do not occur. This mainly seems to happen when > there are a lot of events being scheduled and processed (>1000 events/s). > > > > 2. processTimedEvent sometimes executes concurrently with > processDownstreamPacket for the same layer on the same NEM (apparently in > separate threads). This doesn't occur that often, but I have seen it once or > twice. This may be by design, but I didn't see this documented anywhere and > it means I will probably need to lock my internal data structures before > operating on them in either function. Also, if this is the case, are there > any MAC layer functions that can be considered mutually exclusive, or will > they all need to be locked? > > > > If anyone has any insight on these issues, I would appreciate their > contribution. > > > > Thanks, > > --Benjamin "Russ" Hamilton > > > > > > > _______________________________________________ > emane-users mailing list > [email protected] > http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users > _______________________________________________ emane-users mailing list [email protected] http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users
