BUG: Race Between 2 Threads Sharing a Socket Causes Problem

ID: Q126346

The information in this article applies to:

Microsoft Win32 Device Development Kit (DDK) for Windows NT version 3.5

SYMPTOMS

Packets between the TCP, UDP, and IP layers are lost.

CAUSE

There appears to be a problem with a race condition between two threads that share a socket where one is closing a socket while the other tries to call recvfrom() on the same socket. This causes problems the next time a socket is bound to the same UDP port.

RESOLUTION

The vendor should implement a workaround within the application so that this race condition does not occur.

STATUS

Microsoft has confirmed this to be a problem in the Microsoft products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

MORE INFORMATION

This Sockets/UDP problem was discovered while testing the TX1000 NCPI driver for Windows NT. Here are some notes showing what appears to be happening:

Thread 1                        Thread 2
--------                        ---------

Create DGRAM socket x Bind socket x to:

        IPADDR = ANY
        PORT = 1571

Create thread 2 ----------------->

                                RecvFrom on socket x
                                ...
                                Packet received on x (recvfrom completes)
                <---------------signal main thread
Process rec'd packet            wait for main thread to consume buffer

Signal buffer available--------->

                                RecvFrom on socket x
                                ...  { repeats many times }

Normal Shutdown Sequence (on Last Packet)

                                Packet received on x (recvfrom completes)
                <---------------signal main thread
Process rec'd packet            wait for main thread to consume buffer

Signal buffer available--------->

Application done                (1) RecvFrom on socket x

(2) close socket x

                                (3) RecvFrom fails with expected error
                                Thread terminates

Usually, events occur in sequence (1, 2, then 3). In this normal case, the socket is cleared correctly, and everything works the next time the application runs.

Shutdown Sequence that Causes Problems (on Last Packet)

                                Packet received on x (recvfrom completes)
                <---------------signal main thread
Process rec'd packet            wait for main thread to consume buffer

Signal buffer available---------> Application done

(1) close socket x              (2) RecvFrom on socket x
                                (3) RecvFrom fails with expected error
                                Thread terminates

In this case, the sequence is slightly different. The closesocket() function from main thread starts, but does not complete, before thread 2 runs. While thread 1 is suspended awaiting completion of closesocket(), thread 2 runs and posts next recvfrom() on same socket. The closesocket() function completes successfully, and recvfrom() fails as in normal case. But the next time the application runs and binds to the same UDP port, the following occurs:

All socket calls (bind(), recvfrom()) are successful
All incoming packets to that UDP port are discarded before reaching the application -- recvfrom() never completes. The following command shows that the "receive errors" count has been incremented once for each incoming packet that was lost:
netstat -s -p udp

The conclusion is that in this case the socket was not cleaned up properly due to the race condition between the closesocket() and the recvfrom() functions.

Additional query words:

Keywords          : kbnetwork kbIP kbNTOS350 kbSDKPlatform kbWinsock kbGrpNet 
Issue type        : kbbug

Last Reviewed: August 6, 1998