带锁的多线程与单线程？
我正在设计一个客户端和服务器套接字程序。 我有一个文件要使用 UDP 从客户端传输到服务器，我重复一遍我正在使用 UDP...... 我通过UDP发送，所以发送速率比接收器太快，所以我创建了3个线程在同一个套接字上侦听，这样当一个线程正在做一些工作时（我的意思是使用fwrite写入文件）接收到的数据其他线程可以从客户端接收。
我的第一个问题是，当我在多个线程中使用 fwrite 时，我必须使用锁，因为文件指针在线程之间共享。我的想法是对的？？？
我的第二个问题是“如果我使用多个线程使用锁进行 fwrite，而不是使用单个线程进行无锁的 fwrite 工作，性能会有任何改进吗？？？？”...请指导我.. 。
I am designing a client and server socket program.
I have a file to be transferred to the server from the client using UDP, I repeat I am using UDP.....
I am sending through UDP so, the sending rate is too fast then the receiver, so I have created 3 threads listening on the same socket, so that when one thread is doing some work(I mean writing to a file using fwrite) with the received data the other thread can recv from the client.
My 1st question is when I am using a fwrite with multiple threads I have to use locks as the file pointer is shared between the threads. I am right in thinking???
My 2nd question is "Will there be any improvement in the performance if I use multiple threads to fwrite using locks over using a single thread to do the fwrite work with no locks...??? " ... Please guide me...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我会使用一根线程。省去了并发症。您可以缓冲数据并使用异步写入
http://www. gnu.org/s/hello/manual/libc/Asynchronous-Reads_002fWrites.html
I would use one thread. Saves the complications. You can buffer the data and use asynchronous writes
http://www.gnu.org/s/hello/manual/libc/Asynchronous-Reads_002fWrites.html
在写入数据之前缓存数据。
让写作发生在另一个线程中。
按照您的方式进行操作将需要锁定套接字。
Q1：是的，你确实需要锁定它（非常慢！）。为什么不在每个线程中使用单独的文件描述符？问题主要出在该描述符管理的当前文件位置。
Q2：都不是。如果数据需要排序（是的，UDP！），您仍然应该缓冲它。 RAM 比磁盘 IO 快得多。提供一个流来缓冲它并在单独的线程中处理该流中的数据。
Cache the data before writing it.
Let the writing happen in another thread.
Doing it the way you do will require locking the socket.
Q1: yes you do need to lock it (very slow!). Why not use a separate file descriptor in each thread? the problem comes mostly with the current file position managed by that descriptor.
Q2: Neither. If data needs ordering (yes, UDP!) you should still buffer it. RAM is much faster then disk IO. Feed a stream to buffer it and handle the data in that stream in a separate thread.
类似于 Ed 的回答，我建议使用服务器的异步 I/O 和单线程。虽然我发现使用 Boost.Asio 比 posix AIO 更容易。
Similar to Ed's answer, I'd suggest using asynchronous I/O and a single thread for your server. Though I find using Boost.Asio easier than posix AIO.
的，当多个线程写入单个对象（文件、内存等）时，您始终必须使用锁）。
我会使用两个线程。第一个线程除了从套接字读取数据并将数据存储在内存中之外什么也不做。第二个线程从内存读取数据并将其写入文件。将内存缓冲区视为 FIFO 队列，并使用互斥锁来保护队列指针。你不会从第三个线程中获得任何东西。事实上，这可能会损害性能，并且肯定会使问题变得更加复杂。
Yes, you always have to use locks when multiple threads are writing to a single object (file, memory, etc).
I would use two threads. The first thread does nothing but read from the socket and store the data in memory. The second thread reads data from memory and writes it to the file. Treat the memory buffer as a FIFO queue and use a mutex to protect the queue pointers. You'll gain nothing from a third thread. In fact, it would probably harm performance and it definitely makes the problem far more complicated.
首先，尽量避免使用 UDP 进行批量传输。如果您使用 UDP，则必须重新发明自己的流量控制协议以及重传和重新排序的逻辑。从听起来来看，您的问题归结为缺少流量控制 - 那么为什么不直接使用 TCP 呢？
无论如何，不要把你的文件写入另一个线程中。现代操作系统在任何情况下都会在内部缓冲磁盘写入 - 只有当您写入数据的速度比磁盘跟上的速度快得多时，您才会开始阻塞，在这种情况下，进程内部的缓冲最多只会为您多争取几秒钟的时间。切换到 TCP，或实施适当的流量控制机制。
First, try to avoid using UDP for bulk transfers. If you use UDP you have to reinvent your own flow control protocol, as well as logic for retransmission and reordering. From the sounds of it, your problems boil down to missing flow control - so why not just use TCP?
Anyway, don't put your file writing in another thread. Modern OSes will internally buffer disk writes in any case - you'll only start blocking if you're writing data much faster than the disk can keep up, in which case buffering inside your process will only buy you another few seconds at most. Switch to TCP, or implement a proper flow control mechanism.