- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
In Visual Studio 2022 I have a simple Server-Client application that uses the winsocket2 library. On the main thread the Server in a loop accepts connections. When a connection is established a thread is spawned which is used for handling the communication with a Client through the new socket. This detached thread reads and replies to the Client messages and once the communication is finished the socket is destroyed. To get an idea how the Server is implemented, here is the sample code I used from Microsoft's webpage and I made little change to it to get the above described behavior. The Client code is not too relevant in this context because the analysis is about the Server. In short the Client makes the connection to the Server, after a few sends and receives shuts down the connection.
I'm using Intel Inspector 2023.2 to look for data races in the code. The analysis I perform is 'Threading Error Analysis' with maximum time overhead 40x-160x, the 'Stack frame depth' is 32, the 'Scope' is 'Extremely thorough' and I tick the 'Remove duplicates', 'Use maximum resources' and 'Filter guaranteed atomics' options. I launch the Server application in Inspector and several Client applications from the desktop on the same machine. What I observed is that some data races are reported inside the functions of the winsocket2 library. I also noticed that the data races only happen after the connection is closed. Here is a list of the winsocket2 functions where the data races appear: shutdown, accept, recv, closesocket, setsockopt. Sometimes the data race is between a memory allocation (using std::make_shared or std::vector::assign) and one of the previously mentioned functions.
Does anybody have experience in this kind of analysis using Windows Sockets 2 and could tell if they too noticed this behavior? I'm inclined to believe that the reported data races might be false positives. I doubt that there is an error in the winsocket2 library, also it could be me who is doing something wrong. I suspect that Inspector for a reason cannot handle well memory recycling. In this case I'm referring to the socket memory that after closure is being reused on different threads and this confuses Inspector. Still, I'm open to hear any explanation about this issue, I'm really curious what it could be.
Regards,
Istvan Nagy
Link Copied
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page