[lwip-devel] [patch #5960] Enable multithread send/recv operations on same socket on TCP netconns

[Atte Kojo]

Follow-up Comment #23, patch #5960 (project lwip):

If I've understood correctly there are actually two multithread issues here.

First case is where connection state is not sufficiently protected against
current access from a user thread and tcpip thread. Protecting against this I
could come up with two different ideas. First is to protect each connection
using a per-connection mutex. Second is to protect all accesses to lwip
internal data structures using a traditional BSD-style giant (global) mutex.

Second case, which is the issue with the original patch, is how to protect a
connection from concurrent access of several user threads. My first
suggestion to this would be: don't do it. What even is the supposed result
when multiple threads try to recv from the same socket? Everyone gets the
same data? Each threads gets a chunk of data in a round-robin fashion?
Protecting against this is done similarly as in the previous case: another
per-connection mutex for locking the connection over an api call or a global
mutex locking the whole netconn api during an api call.

Actually, using a giant mutex for lwip would eliminate the need for api and
callback messages completely, but isn't probably otherwise a very good idea
;-).

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?5960>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/