CODEWITHSUNDEEP
c++socketsmutex
Invictus
Invictus

Reputation: 2780

Multiple threads with locks vs single threads?

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...

Upvotes: 1

Views: 319

Answers (5)

bdonlan
bdonlan

Reputation: 231143

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.

Upvotes: 1

Sam Miller
Sam Miller

Reputation: 24174

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.

Upvotes: 1

long404
long404

Reputation: 1035

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.

Upvotes: 2

Ed Heal
Ed Heal

Reputation: 59997

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

Upvotes: 2

Carey Gregory
Carey Gregory

Reputation: 6846

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

Yes, you always have to use locks when multiple threads are writing to a single object (file, memory, etc).

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...??? "

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.

Upvotes: 1

Related Questions