Rif.: Is InetPing thread-safe?

[vix]

I've just found a strange issue in my application and I suspect some kind of race condition.

It seems that InetPing() is somehow involved in this strange behavior and I call it from two different threads.

It can happen that sometimes the calls from the two threads are "simultaneous" and so I wonder if InetPing() is thread-sfae or it's not.

Could someone clarify this, please?

[alamanna]

Hi Vix,

could you send the code that shows this strange behavior, please?

Regards,

Alessia

[vix · Accepted solution]

Hello Alessia,

thank you for your answer.

In the meanwhile I was able to find the reason for the issue and I'm going to report the solution here.

I don't know if InetPing() either is threadsafe or is not, but my issue came from another direction.

I try to explain:

• Prototype for InetPing() is

  int InetPing (const char *address, int *available, unsigned int timeout);

• if the parameter address is an empty string, the function returns an error (as expected)
• in this scenario, the value pointed by parameter available is not changed (and it keeps the value it has before the function call)
• if this value is a local variable (i.e. it's allocated on the stack) and it's not explicitly set before the call, it can have an unpredictable value (and this value can change from call to call). C99 standard states that "If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate.". Moreover it can be that in debug mode variables are initialized automatically but in release they are not.

So a couple of errors from my side:

1. I didn't take care of error returned by InetPing() in the proper way
2. I defined available as a local variable (i.e. allocated on the stack) without explicitly initializing it (to 0)

Handling them in the proper way fixed the issue.

[alamanna]

Hi Vix,

thank you very much for sharing your solution!

Kind regards,

Alessia