DCE Cradle, PthreadFiber: All Fibers are waiting on a condvar

[Richard Sailer]

Hi,

I'm implementing a Multipath Tunneling system with DCCP tunnels in ns-3 with DCE Cradle.

In the setup phase and first second of the simulation I setup my nodes, my networks and my Tunnel Client and Server Application.

Then when the first arp request comes to travel through my tunnel (when I setup the virtualNetDevice) I call the Send() of an Dccp Socket.

By this moment there are a lot (>40) of pthreads and all are waiting on a condvar. When I look at it with gdb, every pthread is in PthreadFiberManager::Yield(),

at the following line:

              volatile PthreadFiberThread *thread = fiber->thread;
              NS_LOG_DEBUG ("Yield after setjmp before wait");
              // wait for the master thread to re-schedule us.
-->          pthread_cond_wait (&((PthreadFiberThread *)thread)->condvar,
                                           &((PthreadFiberThread *)thread)->mutex);

Even the thread with id 1 (in gdb), which is, I assume the master thread. Why does this happen? What did I do wrong?

Thank you,

-- Richard

[Richard Sailer]

Hi,

Some updates I found out through further digging with gdb:

• The main thread blocks in Yield() (as above) on a return from the linux kernel libos. Dccp requested to add a timer
• On the way it calls ExecOnMain(). The safety checks here don't recognize we're on the main thread. It acts like it's an application thread and tries SwitchTo() to the main thread, which blocks forever.
• The problem is from->thread->func != NULL . So maybe the right question is: "Why is func not null, although we are in the main thread?"

[Matt Anonyme]

is func properly initialized to null ?

[Richard Sailer]

Hi,

Am Sonntag, 16. Februar 2020 17:45:55 UTC+1 schrieb Matt Anonyme:

is func properly initialized to null ?

Yes it is, by the constructor.

However I managed to solve this. It seems that DCE generally doesn't work with VirtualNetDevices. Using them

confuses the scheduler. However, if I unset m_current before doing Send() on the VirtualNetDevice and reset it to it's old

value after Send() this is fixed.