Re: [lwip-users] lwip-users Digest, Vol 227, Issue 7

[Peter]

I've spent a day or two on this and found some interesting stuff.

It appears that the mem_ heap used in LWIP *is* already thread safe.
In say mem.c I see

  /* protect the heap from concurrent access */
  sys_mutex_lock(&mem_mutex);
  LWIP_MEM_ALLOC_PROTECT();
#if LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT
  /* run as long as a mem_free disturbed mem_malloc or mem_trim */
  do {
    local_mem_free_count = 0;
#endif /* LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT */

    /* Scan through the heap searching for a free block that is big
enough,
     * beginning with the lowest free block.
     */
    for (ptr = (mem_size_t)((u8_t *)lfree - ram); ptr <
MEM_SIZE_ALIGNED - size;

1st line above does a standard FreeRTOS mutex.

2nd line above is a macro which turns out to be empty but other
instances (not #defined in my project) end up calling the same mutex.
There is also a note that this can be implemented by disabling
interrupts.

So that (the LWIP heap) should be OK.

What I don't know about is whether the socket etc API is likewise
thread-safe. I traced a call to lwip_socket(). Then netconn_apimsg()
then tcpip_send_msg_wait_sem() and that contains

#if LWIP_TCPIP_CORE_LOCKING
  LWIP_UNUSED_ARG(sem);
  LOCK_TCPIP_CORE();
  fn(apimsg);
  UNLOCK_TCPIP_CORE();
  return ERR_OK;
#else /* LWIP_TCPIP_CORE_LOCKING */
  TCPIP_MSG_VAR_DECLARE(msg);

  LWIP_ASSERT("semaphore not initialized", sys_sem_valid(sem));
  LWIP_ASSERT("Invalid mbox", sys_mbox_valid_val(mbox));

  TCPIP_MSG_VAR_ALLOC(msg);
  TCPIP_MSG_VAR_REF(msg).type = TCPIP_MSG_API;
  TCPIP_MSG_VAR_REF(msg).msg.api_msg.function = fn;
  TCPIP_MSG_VAR_REF(msg).msg.api_msg.msg = apimsg;
  sys_mbox_post(&mbox, &TCPIP_MSG_VAR_REF(msg));
  sys_arch_sem_wait(sem, 0);
  TCPIP_MSG_VAR_FREE(msg);
  return ERR_OK;
#endif /* LWIP_TCPIP_CORE_LOCKING */

where the now famous LWIP_TCPIP_CORE_LOCKING is greyed-out (not
defined)!

If I set LWIP_TCPIP_CORE_LOCKING=1 then DHCP stops working and that
code is too complex for me to work out.

But it looks like this is the key. No way will this project work
without this, because I have 3 RTOS tasks doing socket calls.

Peter



>Send lwip-users mailing list submissions to
>       lwip-users@nongnu.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>       https://lists.nongnu.org/mailman/listinfo/lwip-users
>or, via email, send a message with subject or body 'help' to
>       lwip-users-request@nongnu.org
>
>You can reach the person managing the list at
>       lwip-users-owner@nongnu.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of lwip-users digest..."
>
>
>Today's Topics:
>
>   1. Re: How to use LWIP from FreeRTOS tasks - a thread safety
>      question (Peter)
>   2. Re: How to use LWIP from FreeRTOS tasks - a thread safety
>      question (Jeffrey A. Wormsley)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 12 Jul 2022 17:17:22 +0100
>From: Peter <peter@peter2000.co.uk>
>To: Dave Nadler <drn@nadler.com>
>Cc: Mailing list for lwIP users <lwip-users@nongnu.org>
>Subject: Re: [lwip-users] How to use LWIP from FreeRTOS tasks - a
>       thread safety question
>Message-ID: <202207121617.26CGHNS3094625@mail.authsmtp.com>
>Content-Type: text/plain; charset=us-ascii
>
>
>
>>Hi Peter - Can you start at the beginning?
>>Has this ever worked, or for 2 years it always crashed if you used LWIP?
>>What exactly "crashes the whole thing"?
>>You're aware of the numerous issues surrounding STM-provided Ethernet 
>>driver?
>>Hope this helps,
>>Best Regards, Dave
>
>I have spent more time on that LWIP_TCPIP_CORE_LOCKING=1 issue.
>Tracing through the code, it does appear that eventually LWIP does end
>up using FreeRTOS mutexes.
>
>It breaks something else however, and I can't easily trace it because
>DHCP fails to work, and one can't really trace that because taking a
>breakpoint causes timeouts etc. Also that code is too convoluted for
>me to understand :)
>
>I have been trying to find advice around the place and this post
>summarises my latest findings on this
>
>https://www.eevblog.com/forum/microcontrollers/lwip-32f417-how-to-optimise-network-stack-memory-allocation/msg4295431/#msg4295431
>
>
>
>------------------------------
>
>Message: 2
>Date: Tue, 12 Jul 2022 13:50:21 -0400
>From: "Jeffrey A. Wormsley" <daworm@gmail.com>
>To: Mailing list for lwIP users <lwip-users@nongnu.org>
>Cc: Dave Nadler <drn@nadler.com>
>Subject: Re: [lwip-users] How to use LWIP from FreeRTOS tasks - a
>       thread safety question
>Message-ID:
>       <CAF6o3h-+GP6vTSj-9EpZUbup0v959ehEa=4VPGw6CSHkqrQn0g@mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>No real help here, but that CMSIS layer is intended to let you write your
>application to one API, then port it to multiple RTOSes or even full
>desktop/server OSes, presumably without changes.  And digging through that
>code is always (read "never") fun.
>
>Jeff
>
>On Tue, Jul 12, 2022 at 12:18 PM Peter <peter@peter2000.co.uk> wrote:
>
>>
>>
>> >Hi Peter - Can you start at the beginning?
>> >Has this ever worked, or for 2 years it always crashed if you used LWIP?
>> >What exactly "crashes the whole thing"?
>> >You're aware of the numerous issues surrounding STM-provided Ethernet
>> >driver?
>> >Hope this helps,
>> >Best Regards, Dave
>>
>> I have spent more time on that LWIP_TCPIP_CORE_LOCKING=1 issue.
>> Tracing through the code, it does appear that eventually LWIP does end
>> up using FreeRTOS mutexes.
>>
>> It breaks something else however, and I can't easily trace it because
>> DHCP fails to work, and one can't really trace that because taking a
>> breakpoint causes timeouts etc. Also that code is too convoluted for
>> me to understand :)
>>
>> I have been trying to find advice around the place and this post
>> summarises my latest findings on this
>>
>>
>> https://www.eevblog.com/forum/microcontrollers/lwip-32f417-how-to-optimise-network-stack-memory-allocation/msg4295431/#msg4295431
>>
>> _______________________________________________
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
><https://lists.nongnu.org/archive/html/lwip-users/attachments/20220712/e1a0f157/attachment.htm>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
>------------------------------
>
>End of lwip-users Digest, Vol 227, Issue 7
>******************************************