lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [bug #32784] Race condition when sending to UDP socket from


From: Ken MacKay
Subject: [lwip-devel] [bug #32784] Race condition when sending to UDP socket from multiple threads
Date: Mon, 14 Mar 2011 21:10:58 +0000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-us) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4

URL:
  <http://savannah.nongnu.org/bugs/?32784>

                 Summary: Race condition when sending to UDP socket from
multiple threads
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: kmackay
            Submitted on: Mon 14 Mar 2011 09:10:57 PM GMT
                Category: UDP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: CVS Head

    _______________________________________________________

Details:

When multiple threads are sending over the same UDP socket (using sendto()),
there is a race condition in tcpip_apimsg(). What happens is that one thread
(thread 1) enters tcpip_apimsg() and posts to the tcpip thread. The tcpip
thread then runs the do_send function and signals the conn->op_completed
semaphore. Then the tcpip thread goes back to blocking on the mbox.

At this point, if a different thread (thread 2) is selected to run, the
conn->op_completed semaphore is already set. That means that when thread 2
calls sendto() and enters tcpip_apimsg(), it posts the operation to the mbox
and then waits on the semaphore. Since the semaphore is already signalled, it
returns immediately. Then, when the tcpip thread runs the operation, it
corrupts the stack of thread 2.

I fixed this issue by adding a semaphore to struct lwip_sock, and locking it
while calling netconn_send() in lwip_sendto(). I'm not sure if this is the
best way to do it though.

I'm not sure what the correct behaviour is here. Sending to a UDP socket from
multiple threads works on other platforms. However, it is not difficult for
the application to manage the locking properly. The locked region would be
larger than if the locking were done in lwIP itself.

It seems like sending to / receiving from a UDP socket from multiple threads
should work since UDP sends datagrams; I wouldn't expect it to work with TCP
since the stream would get garbled. Note that I didn't try receiving from
multiple threads, but I assume it works in a similar way.




    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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