CONCURRENT, UNBUFFERED TCP SEND OPERATIONS

```
Description: At present, there cannot be two concurrent active TCP send
operations in progress using the same socket *unless*
CONFIG_TCP_WRITE_BUFFER. This is because the uIP ACK logic
will support only one transfer at a time.

Such a situation could occur if explicit TCP send operations
are performed using the same socket (or dup's of the same)
socket on two different threads. It can also occur implicitly
when you execute more than one thread over and NSH Telenet
session.

There are two possible solutions:

1. Remove option to build the network without write buffering
enabled. This is is simplest and perhaps the best option.
Certainly a system can be produced with a smaller RAM
footprint without write buffering. However, that probably
does not justify permitted a crippled system.

2. Another option is to serialize the non-buffered writes for
a socket with a mutex. i.e., add a mutex to make sure that
each send that is started is able to be the exclusive
sender until all of the data to be sent has been ACKed.
That can be a very significant delay involving the send,
waiting for the ACK or a timeout and possible retransmissions!

Although it uses more memory, I believe that option 1 is the
better solution and will avoid difficult TCP bugs in the future.

Status: Open.
Priority: Medium-Low. This is only an important issue for people who
use multi-threaded, unbuffered TCP networking without a full
understanding of the issues.
```