Programming

Situation:
i have multiple pthread_create calls like this:

pthread_create(...., ThreadFunc1,.....);
pthread_create(...., ThreadFunc2,.....);
.
.

which i am using to create multiple threads.All the "ThreadFunc<i>" functions are actually calling same function "Receive" of a class using same object of that class like this:

ThreadFunc1()
obj.Receive(<socket 1>); //receive data from socket 1

ThreadFunc2()
obj.Receive(<socket 2>); //receive data from socket 2

Question:
1.Will all the threads have their own copies of function "Receive", in order to provide concurrent receiving from all the receive sockets in application.

2. How is this approach different from:

while(1)
obj.Receive(<from all sockets one by one>);

where the same function polls all the receive sockets one by one to see for any data on them.

You almost certainly need synchronization somewhere inside ::Receive() to prevent race conditions -- two threads blindly overwriting the same variable, unaware of the other changing it while they were asleep -- but nothing prevents this except whatever synchronization you do yourself. How efficient this is under high load depends on how much waiting the threads have to do for each other to avoid race conditions. If Receive() does a lot of processing before actually altering or using the object members in any way, most of that could happen concurrently, but if all it does is update the object, almost nothing should happen concurrently, making the threads mostly pointless.

Polling isn't a good idea in either case though, given a better alternative: Have you tried select()? It can wait for activity on an entire set of file descriptors without polling. Once activity happens, you can hand the file descriptor it reports off to a thread for processing if advantageous, or just feed it to Receive() if not.

"If Receive() does a lot of processing before actually altering or using the object members in any way, most of that could happen concurrently, but if all it does is update the object, almost nothing should happen concurrently, making the threads mostly pointless."

Can u please elaborate this point...

I'd just be restating what I said already: Things that don't contend for the same resource can be done concurrently. Using local variables isn't contention, but global variables would, static variables would, and class members would. Modifying any of those would be contention, which would need a mutex to guarantee that only one thread at a time uses it -- that is, reads OR writes it -- at once.

Ergo, if modifying class members is nearly all that Receive() does, there's not a lot of point in multithreading it since you'll have to force them to use the object one-at-a-time anyway to avoid race conditions. What else did you want to know?