[lwip-devel] [bug #23240] recv_udp increases counters for available receives before netbuf is actually posted

[Kieran Mansley]

Follow-up Comment #10, bug #23240 (project lwip):

I've been looking at this and don't really like any of the proposed
solutions.

While the making rcvevent and recv_avail might just about end up with the
right functionality, I don't like that between doing the trypost and
incrementing recv_avail the state would be in an inconsistent state, and this
could be so for some time if the trypost causes another thread to execute.

My preferred way of doing it would be to add to the mbox API and have a
sys_mbox_tryreserve() which would see if there was a free slot in the mbox,
and if so leave the mbox locked so that it couldn't be taken by another
thread.  If this returned true you'd know that the post operation was going to
be successful, you could increment the counters in a sensible order, then do a
sys_mbox_postreserved() which would post the message and unlock the mailbox. 
If tryreserve() returned false you'd just give up at that point without having
to undo any state changes you'd made already:

if(sys_mbox_tryreserve() {
  /* Slot in mbox is reserved, mbox is left locked */

  SYS_ARCH_INC(conn->recv_avail, p->tot_len);
  /* Register event with callback */
  API_EVENT(conn, NETCONN_EVT_RCVPLUS, p->tot_len);
  sys_mbox_postreserved();
} else {
  /* Slot in mbox not available, mbox is not left locked */

  netbuf_delete(buf);
  return;
}

The only problem I can see with this is (i) it requires a change to the API,
so ports need updating and (ii) if API_EVENT tried to access the mbox it would
find it was locked, which could lead to deadlock.  I'm not sure if this is
likely or a problem.  I guess it is the same as using a semaphore as proposed
in comment#3 but using the mbox protection instead of a new semaphore.


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?23240>

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