Which thread models should I use for high performance sockets?

Hi,

I am working on a project that will be working under extreme high loads.

I will like to know which thread model and socket functions should I use to meet the following requirement:

1) a socket client program that connects to a server program. This server program will be sending large number of socket messages to the client per seconds. I am expecting about 20 messages per seconds.

2) this program utilises memory queue and has been implemented in the form of lbrary. I am thinking of using threads to queue the messages into the mem queue as fast as possible.

3) After the message has been inserted into the memory queue, there will be a callback function that retrieves the messages and decode it and then puts it back into another memory queue which will send it to another server program.

As I am new to multi thread programming concets, I am not sure on how I can program it in C language. Will appreciate if some of you can give me some hints or
guide. Do u think that I need to use mutexes? My idea is to have a simple program that just create a thread and sends it into queue, process it and sends it into another queue to send out.

Also is there any special socket libraries that I need to use to achieve such high performance?

Please advise. Thanks.

Regards,
CM
hocheemingAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jkrCommented:
What OS? If "Windows", I'd suggest to use I/O completion ports, which serve exactlx this purpose. See http://win32.mvps.org/network/sockhim.html
hocheemingAuthor Commented:
I am using Redhat Linux 7.3
cupCommented:
I'd do it the way you've suggested.  Use pthreads on linux.

If you're using a linked list where one thread adds and another removes, there is no need for mutexes since changing a pointer is an atomic operation.  It will be even faster if you preallocate the buffers and just fill them in as you receive the messages.

Alternatively, create an array for the buffers and use the indices to mark the head and tail.  Only move them on when you have completed writing to the buffers.  Again, since moving the head and tail are atomic operations (head = (head + 1)% buffmax), you won't need mutexes.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Exploring SQL Server 2016: Fundamentals

Learn the fundamentals of Microsoft SQL Server, a relational database management system that stores and retrieves data when requested by other software applications.

Kent OlsenDBACommented:


>If you're using a linked list where one thread adds and another removes, there is no need for mutexes since changing a pointer is an atomic operation.  It will be even faster if you preallocate the buffers and just fill them in as you receive the messages.

Very true.  :)

Keep in mind that if you're going to work without a net (no locking, mutexes, etc.) that you must be extremely careful to do things in the correct order.

When you add a node to the list, you MUST set the node's "Next" pointer before inserting it into the list.  Otherwise you run the risk of having the node added to the list and another thread processing the list before the node's next pointer is properly set.


Kent
hocheemingAuthor Commented:
I am using a memory queuing api which I think should be using linked list. It has been taken care of and should be working fine. Another think that I will like to clarify is.. I am not clear on the use of pthread_join API. My understanding is that when I use pthread_create to create a thread and then later use pthread_join, the main process will actually wait for the thread to finish at pthread_join before continuing execution. Does it means that I actually do not create a thread at all and can just use the main process to execute?

How can I make use of pthread in such a way that threads will be spawned when messages had comes in so that the messages will be quickly dealt with and result in minimum loss of socket messages?
billtouchCommented:
For a very good tutorial on pthreads, look at this paper rom IBM.

http://www-128.ibm.com/developerworks/linux/library/l-pthred.html

A thread will execute until it is blocked. Other threads can continue to run. When you issue a read to get a message, unless you use special code to do a non-blokingn read, the program will wait on the read to complete. It is a good idea (and makes for simpler code) to run the read in a separate thread. Depending of the work that is asked for by the message, you may want to spawn worker threads to do the processing or you could do the processing in the main thread.

As for performance, what target are you trying to reach. Socket handling is pretty efficient using linux. It is al built into the kernel. Threads on the other hand are not that efficient. Spawning a thread is the same as starting a new process. In fact it is starting a new process with the main thread as the parent and it shares the same memory space.

The most efficient way to do this is to figure out the number of threads you need and start them at program initializatoin and dispatch them when there is work for them.

Bill
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Editors IDEs

From novice to tech pro — start learning today.