带锁的多线程vs单线程

我将使用一个线程。避免了并发症。您可以缓冲数据并使用异步写

http://www.gnu.org/s/hello/manual/libc/Asynchronous-Reads_002fWrites.html

写入前缓存数据。让写作在另一个线程中进行。

这样做将需要锁定套接字。

Q1:是的，你确实需要锁定它(非常慢!)为什么不在每个线程中使用单独的文件描述符?这个问题主要是由该描述符管理的当前文件位置引起的。

Q2:没有。如果数据需要排序(是的，UDP!)，您仍然应该缓冲它。RAM比磁盘IO快得多。提供一个流来缓冲它，并在单独的线程中处理该流中的数据。

与Ed的回答类似，我建议您的服务器使用异步I/O和单线程。虽然我发现使用Boost。

我的第一个问题是当我使用多个线程的fwrite时，我必须使用锁作为文件指针在线程之间共享

是的，当多个线程写入单个对象(文件，内存等)时，您总是必须使用锁。

我的第二个问题是"如果我使用多个线程使用锁进行fwrite，而不是使用单个线程在没有锁的情况下进行fwrite工作，性能会有任何提高吗??"

我会使用两个线程。第一个线程只从套接字读取数据并将数据存储在内存中。第二个线程从内存中读取数据并将其写入文件。将内存缓冲区视为FIFO队列，并使用互斥锁来保护队列指针。从第三条线程中您将一无所获。事实上，它可能会损害性能，而且肯定会使问题更加复杂。

首先，尽量避免使用UDP进行批量传输。如果你使用UDP，你必须重新设计你自己的流量控制协议，以及重传和重新排序的逻辑。听起来，您的问题归结为缺少流量控制——那么为什么不直接使用TCP呢?

无论如何，不要把文件写入到另一个线程中。现代的操作系统在任何情况下都会在内部缓冲磁盘写操作——只有当你写数据的速度远远超过磁盘的速度时，你才会开始阻塞，在这种情况下，进程内部的缓冲最多只能为你多争取几秒钟的时间。切换到TCP，或者实现适当的流量控制机制