lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] lwIP 2.0.0 IPV6 Thread Awareness


From: josephjah
Subject: [lwip-users] lwIP 2.0.0 IPV6 Thread Awareness
Date: Thu, 6 Oct 2016 15:44:34 -0700 (MST)

Hello again everyone, 

I've got a question about thread-safety using 2.0.0 in IPV6 mode. I've tried
searching for a solution on here but I'm somewhat stumped and could use some
help. 

Prior to this I've been using the 1.4.1 core in IPV4 mode, each call to the
core was surrounded with a mutex. Like such:

inline void __tcp_tmr(void) throw() { Mutex::Lock _l(_lock); return
_tcp_tmr(); }

This functioned very well (as a prototype) using one global mutex for all
calls. However after upgrading to 2.0.0 and using it in IPV6 mode, I get a
number of deadlock scenarios. I've resolved one of them by introducing a
separate mutex for pbuf_alloc (say, _lock_mem) and one for everything else
(_lock). This works 99% of the time, but I keep getting into the following
quagmire:

On line 1093 of tcp_out.c I've observed that useg is NULL. I've read that
this is due to a thread conflict in almost all cases. So I've tried
introducing finer granularity to my locks but I can't seem to pin down a
solution.

Is there any sort of guideline to how calls should be locked? Short of
diagramming out the entire core and finding every possible conflict and
determining some set of locks I can use, I'm not sure how to go about this.

Any help would be greatly appreciated!

- Joseph



--
View this message in context: 
http://lwip.100.n7.nabble.com/lwIP-2-0-0-IPV6-Thread-Awareness-tp27528.html
Sent from the lwip-users mailing list archive at Nabble.com.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]