Consultation: whether the socket needs to be locked when writing multiple threads at the same time

First, yes, because the socket is duplex.

Multiple Threads read and write the same socket.
If the problem persists, unless multiple threads have the same effect.

This struct exists in TCP/TP Volume 2.
Struct sockbuf {

Short sb_flags;
..........
} So_recv, so_snd;
Among them, the flag has these signs:
Sb_lock; a process has locked the plug-in cache.
Sb_want; a process is waiting to lock the plug-in cache.

There are also some macros and functions to manage the sending and receiving caches of the plug-in.
Sblock, sbunlock, sbwait (page 388,389)
That is to say, the socket has actually taken this into account. Do we only need
Some operations, such as setting some flag spaces or some Macros?

Continue to translate the implementation of send,
The following code is found:

If (error = sblock (& so-> so_snd, sblockwait (FLAG )))
Goto out;
Do {

.......

}

When sending a message, the function first locks the cache. By locking it, multiple processes are mutually exclusive in order to access the plug-in cache. (TCP/IP volume 2, page 394,395)
That is to say, the system has already helped us do this.

Multi-thread socket writing should be locked, and the returned value must be equal to the length of the data to be sent or error before unlocking. Although the kernel may

Automatic lock, but if the socket buffer is insufficient to accommodate all the data of the user, the thread will enter the sleep state. Will the system unlock and implement

Close it

The socket should be locked. Especially for non-blocking sockets, locking the buffer at the underlying layer does not solve the problem of data interruption.

I think flw2 is about to lock you at send_n.
Although the system send is atomic, it is not guaranteed that send_n is atomic. Therefore, a lock is required to ensure that after thread a send_n is complete.
Thread B and send_n.

When I first learned network programming, I was also stupid enough to lock the socket. Later I used code verification without locking: lol:

Generally, multiple worker threads write the data to be sent to a lock buffer, and the other thread sends and receives data separately. Direct Writing by multiple threads

Socket has never done so. I think it should be locking, and the number of sent bytes must be determined to be equal to the number of sent bytes.

Locks are required. Unless sent by a single thread

Stick this post up again, because I encountered this problem today. Write an interface with multiple threads, and read data must be mixed at the application layer, for example

Thread T1 needs to write 100 'A' and thread T2 needs to write 100 'B'. In fact, the data received by the other party is a mixed with B, this makes no sense at all. Some people say

Write is atomic, But we generally use writen. It is seldom called once to return data regardless of the result. You can close it.

The write operation on the socket is not atomic from the user's point of view, because if 1 MB of data is sent at a time, it is definitely not Atomic. As for how much data is sent at a time, It is good

There is no clear saying (it is best not to make atomic assumptions) (it has nothing to do with Mtu, It is the underlying subcontracting)

In the final analysis, there are two conclusions:

1. Avoid multiple threads simultaneously operating on one socket.

2. If the above situation cannot be avoided, the lock should be applied.

Correct?

If multiple threads need to read and access the same TCP socket at the same time, most of them are due to programming problems.

For TCP transmission, the receiver must use the Protocol at the application layer to ensure that the data sent by the other party can be interpreted. In this way, at least one piece of data must be a complete association.

Package.

If multiple threads write socket at the same time, the thread working in the critical section must send and wait cyclically to ensure the complete transmission of data packets until the data is sent

To the system buffer zone, you can leave the critical zone.
In this way, the socket behavior is no different from the blocking method, and the sending efficiency is limited.

I think a good TCP socket Processing framework should have only one thread responsible for sending and receiving data, so as to avoid endless synchronization problems.

If multiple threads need to read and access the same TCP socket at the same time, most of them are due to programming problems.

For TCP transmission, the receiver must use the Protocol at the application layer to ensure that the data sent by the other party can be interpreted. In this way, at least one piece of data must be a complete association.

...

Positive solution!

In fact, this situation is very common. Why is it a design problem?
For example:
A porxy server connects to the client and port 80 of the server. Each client's connection is processed as a thread and client messages are forwarded to the service.

.

Proxy, a connection to the server is established for a client connection.
Therefore, there are no mixed cases.

Different flow packages are mixed in one link, which is a problem in design.

If multiple threads need to read and access the same TCP socket at the same time, most of them are due to programming problems.

For TCP transmission, both...

Agree