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

[Simon Goldschmidt]

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

re comment #23:

>First case is where connection state is not sufficiently protected against
current access from a user thread and tcpip thread.

That should be solved throught the mboxes and callbacks running in
tcpip-thread context.

>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?

As Frédéric said: one task receives, the other sends. Or one task is
blocking in recv(), another can call close() to gracefully shut down an app.
(I don't think that's standard, but it works on some OSes...).

re comment 22#:
>In general condition variables and mutexes are better, as they allow
priority inversion to be prevented (if the OS implements it). That's
impossible with semaphores. So in general, they are better.

Agree!

> [1 mutex per conn]
That would help much, since it would eliminate many OS calls (apart from
mutexes). But here again, semaphores would be a bad idea, mutexes would be
much better!

> [..] All this needs protecting from other threads. It's not only a case of
which thread was intended to get the NULL to the conn->mbox.

You're right, but most of the problems you've stated are not really a race
condition (at least on 32-bit systems) (e.g. conn->pcb.tcp->state is only
read) or can be solved somehow.

But don't get me wrong: You're right that with the current code, changing
conn->mbox to a per-thread mbox (or sem) is not the only thing to do!

I think the idea of having one mutex per netconn is a very good one! (Only we
would have to have mutexes, but could eliminate mboxes).

Then again, maybe it's time to re-write the api layer? :-)
I'd like to have mutexes protecting parts of the stack. That way one could
prioritize RX-frames by processing them in different threads...

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/