[Top][All Lists]
[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/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lwip-devel] [bug #32784] Race condition when sending to UDP socket from multiple threads,
Ken MacKay <=