buglwIP - A Lightweight TCP/IP stack - Bugs: bug #48220, TCPIP_CORE_LOCKING should be the...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #48220: TCPIP_CORE_LOCKING should be the default

Submitter:  Simon Goldschmidt <goldsimon>
Submitted:  Tue 14 Jun 2016 07:30:14 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  2.0.0 Beta2
lwIP version:  git head

Thu 30 Jun 2016 08:39:21 PM UTC, comment #4: 

Done.
Define LWIP_COMPAT_MUTEX_ALLOWED if you really need to use LWIP_TCPIP_CORE_LOCKING && LWIP_COMPAT_MUTEX (which is not a good idea since only mutexes can prevent priority inversion).

Simon Goldschmidt <goldsimon>
Group administrator
Thu 30 Jun 2016 08:24:35 PM UTC, comment #3: 

Right. And it's probably not the only occurrence, so this might not be a good idea...

Simon Goldschmidt <goldsimon>
Group administrator
Tue 28 Jun 2016 01:42:15 PM UTC, comment #2: 

Simon,

I think there is an issue with how the loopback adapter uses tcpip_callback_with_block() that would not work if we converted it to use core locking which executed the callback in place.

In netif_loop_output(), it schedules netif_poll() to run as the callback after the output packet has been queued.  The comment at the top of netif_poll seems to indicate you can't call input from an output function:

/**

  • Call netif_poll() in the main loop of your application. This is to prevent
  • reentering non-reentrant functions like tcp_input(). Packets passed to
  • netif_loop_output() are put on a list that is passed to netif->input() by
  • netif_poll().

 */

It would be nice if we could resolve the reentrancy problems and be able to use the loopback adapter without having a context switch to do the output

Joel Cunningham <jcunningham>
Group Member
Mon 27 Jun 2016 08:59:40 AM UTC, comment #1: 

We might want to change 'tcpip_callback()' (not the non-blocking version) to use LOCK_TCPIP_CORE() instead of posting a message.

However, this might change the behaviour depending on thread priorities (tcpip_callback only enqueues a function but does not wait for it to finish executing).

Simon Goldschmidt <goldsimon>
Group administrator
Tue 14 Jun 2016 07:30:14 AM UTC, original submission:  

LWIP_TCPIP_CORE_LOCKING should perform much better since grabbing a mutex should be faster than 2 thread context switches on most platforms. Also, thread priorites help to schedule which task is served first.

However, we should get people to implement a mutex to prevent priority inversion.

To do this, we could raise an #error if LWIP_COMPAT_MUTEX is 1. (and we should implement mutexes for our example ports :)

Simon Goldschmidt <goldsimon>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jcunningham (Posted a comment)
  • -email is unavailable- added by goldsimon (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-06-30 goldsimon StatusNone Fixed
        Assigned toNone goldsimon
        Open/ClosedOpen Closed
    2016-06-30 goldsimon Planned ReleaseNone 2.0.0 Beta2

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code