Re: [lwip-users] lwIP 2.0.0 IPV6 Thread Awareness

[Dirk Ziegelmeier]

Try to use lwIP 2.0.0 core locking feature instead, it does what you try to do with your own mutexes:

http://www.nongnu.org/lwip/2_0_0/group__lwip__opts__lock.html#ga8e46232794349c209e8ed4e9e7e4f011

http://www.nongnu.org/lwip/2_0_0/pitfalls.html

Ciao
Dirk

--
Dirk Ziegelmeier * address@hidden * http://www.ziegelmeier.net

On Fri, Oct 7, 2016 at 12:44 AM, josephjah <address@hidden> wrote:

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.

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users