Threading design

[MonoT2nic]

I have a server with multiple clients, one separate thread for each client. The server recieves data from the clients and should do something with it(for instance, in case of a chat program, send the message from one client to all the others).

Which of the following two suggestions is to prefer? That I put all the data from the clients in some kind of global (thread-safe of course) data structure and use a separate thread that goes through the data and process it. Or should each client-thread perform everything by itself, as soon as it recieves data? I guess it doesnt really matter, is more of a design question for threading. I think I'll use this for a application where the clients should pass (processed) data to another server, without "direct-connection", everything has to go through the server.

[Naumaan]

Your question is related to two fields 1: Threading Design 2: Socket Programming .

If u want to change ur design only on Thread level then i think u have to push ur all received data in an array(data structure) and ur thread pop such data one by one and process it ( again u have to consider Blocking and Non Blocking socket model to desing ur application ).

If u want to change ur desing through socket models then its a better and prefered way. There are lot of socket models available, you should consider using the I/O completion port model for even better performance.

[sirikrishnap]

It is better the threads process the data rather than sending it to a common thread which processes it. This creates an unnecessary bottle neck. I believe this to be the reason why the app was designed to be multithreaded to interact with multiple clients.

[MonoT2nic]

But the thing is that the computations are kinda heavy (not really, but some database stuff and some calculations). So then it could be a problem since I would have to use some "locked" objects which the threads need to access, which would result in slow performance (cause the threads would be locked up by another very often and wouldnt be able to recieve data). And I would like to use the regular blocking sockets.

[Andreas Masur]

Well....then you should rather change your network setup. Instead of having one thread for each connection, you could rather set up a thread pool instead. Then have one thread processing the incoming messages.

[fts_technology]

Hmm, if your db calls and calculations are independent per client, i.e. you don't *have* to aggregate all the data from multiple clients before making your calls/calcs, then I'd agree with sirikrishnap, making a central thread do the calculations is creating a bottleneck. Here are the disadvantages:

If all N client threads are equal priority and all happen to be active, the central thread will only be able to run db calls and calcs 1/(N+1) of the time. You'll probably have more latency between the time data is received and the time it is consumed. You'll be writing to the data structure from a client thread, letting it sit there, then re-reading the same data from the central thread, which can duplicate the amount of memory operations you're doing, and memory operations are expensive.

Plus, if you went with the central-thread model, you'd still need "locking" for the data structure. You mention a "thread-safe" structure; in reality thread-safe structures use locks internally, they just abstract the synchronisation mechanism from the user.

If it's blocking socket calls you're worried about, just release the lock prior to making the blocking call. The only time you need to hold the lock is when you are using the shared resource (is this your database/calculation mechanism?).