Is the TCP/IP stack re-entrant (thread-safe)?

Is the TCP/IP stack used in NET+OS 7.1 re-entrant (thread-safe)? The stack is developed by Treck and this is what I found in their documentation:
Re-entrant and “Romable”

Also see:
etos71\src reck
etos71\lib\arm7\32b\gnu\libtcpip.a (This file contains a lot of Treck functions).

I’m asking this question here in a new topic because there is a lot of confusion about this topic. Some people say the stack is not re-entrant and also Digi Support says this. But this seems to be very strange, since the Teck documentation says the opposite.

I also have never heard of a any non-reentrant TCP/IP stacks. For example, see:
“I don’t know of any implementations from Microsoft (or any other vendors) that are not thread safe.”

Also see:,1095#4147

P.S. By thread-safe I mean this: Is it safe when one thread is calling send() and another thread is calling recv() on a single socket?

Digi Support: please make this issue clear!

I got this reply from Digi Support:

“The functions of send(), recv() select(), etc are fully reentrant. However, socket calls on the same socket from two different threads at the same time will lead to indeterminate behavior. To resolve this issue it is best to either do all your calls to a single socket within the same thread, or to mutex protect the thread.”

(They mean “mutex protect the socket” I guess)

But finally it is 100% clear clear now.

Only one question remains, though:
Is it safe to do select() in one thread (which blocks until data is ready to be read) and send() in another thread? Like this:

I’m using:

  • two threads
  • one TCP socket
  • one mutex to protect the socket
  • one queue that will be filled with data when something needs to be sent. (the tx_queue_send() calls are done by other threads).

TCP Receive thread:
select(socket,readset) //wait for data to arrive on the socket

TCP Send thread:
tx_queue_receive() //wait for data to be sent

other threads:
tx_queue_send() //when some data needs to be sent