[Top][All Lists]

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

[lwip-devel] [task #6935] Problems to be solved with the current socket/

From: David Empson
Subject: [lwip-devel] [task #6935] Problems to be solved with the current socket/netconn API
Date: Mon, 28 May 2007 23:30:58 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070309 Firefox/

Follow-up Comment #11, task #6935 (project lwip):

_>I at least would be interested in knowing where the stack spends the ~100
extra milliseconds when using mboxes._

That's an extra 128 *microseconds* (0.128 ms) in total, or 87 for the first
solution (replacing an mbox with a global mutex but still using

The current mbox method requires the TCPIP thread to take over and process
the API message from netconn_send/sendto, calling udp_send/sendto. With a
global mutex, I assume the application thread would directly call udp_sendto
(possibly via netconn_sendto), but might be blocked while another thread owns
the global mutex.

Either solution 1 or 2 will therefore be avoiding a context switch, but the
quoted times will be best case results (with the global mutex available).

Do Frédéric's stats for the current CVS method include time required for
context switches, i.e. total elapsed time, or is it just execution times for
the application thread, without any overhead?

Even if it is just execution time for the application thread, there is quite
a lot of overhead in using the mailboxes, notably the construction and
posting of an API message, and several layers of function calls. These could
be adding up to a significant chunk of that 87 microseconds, most of which is
avoided by using a global mutex.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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