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

[Simon Goldschmidt]

josephjah wrote:
> [..] I've taken a look [at LWIP_TCPIP_CORE_LOCKING] and it appears that this 
> is
> designed to be used with NO_SYS==0

That's correct. When using NO_SYS==1, you're back on your own with the 
statement that the lwIP
core is not meant for concurrent access. :-)


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[josephjah]

Thanks for the advice, Dirk. I've taken a look and it appears that this is
designed to be used with NO_SYS==0, currently for my application I have
NO_SYS==1. It appears that I need to do some significant re-engineering of
the core's locking mechanism to make this work for my context, but I suspect
that's a bad assumption. Any ideas?

Whatever the solution I arrive at I'll detail it here for future reference.

Thanks.



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

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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 * d...@ziegelmeier.net * http://www.ziegelmeier.net

On Fri, Oct 7, 2016 at 12:44 AM, josephjah  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
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users