Re: socket lock in multithred programming

From: Ku Jaguk (jkku_at_softeleware.com)
Date: 09/29/05 

Date: Thu, 29 Sep 2005 14:37:32 +0900

Thanks for your answer,

I am make a process, the input and output is like below.
It has two external interfaces those are TCP/IP, asumes A and B.

A -----request----> my process ----request----> B
A <----response--- my process <---response--- B

A <-----request---- my process <----request----- B
A ------response--> my process -----response---> B

The job of my process is filltering the packet, charging by making CDR(call
detailed record) file, reformatting the packet for the oposite prococal
specification.
My process has no database connection.
My process has only one connection to A and B, those are concurrent TCP/IP
connection.
I want my process to handle as many as packet possible.

I can think the possible process model is
1. one process with no thread, it has non-blocking socket to A and B both of
them.
    so it should select() A and B in short time period in while loop.
2. one process with two threads, one thread T1 for A, the other T2 is for B.
    so T1 select() A, read packet and add packet to mutex memory queue, T2
read queue and send it to B.
    T2 read response from B and add it to queue, T1 read it from Queue and
send it back to A.
    T1 and T2 are selecting socket description and polling a memory queue
and working simutenuously and asynchronously.
    one of theads can handle the filltering, charging and reformatting job.
3. one process with two threads, one thread T1 for reading from A and
sending it to B, the other thread T2 is reading from B and sending it to A.
    so T1 read() from A. when it get the packet from A, send it to B and
read() A again.
    T2 read() from B. when it get the packet from B, send it to A and read()
B again.
    one of theads can handle the filltering, charging and reformatting job.
4. there are more working job threads those can handle filltering, charging
and reformatting job with mutex memory queue in case 2.
5. there are more working job threads those can handle filltering, charging
and reformatting job with mutex memory queue in case 3.

I thought case 3 would be OK for me, but i am wondering there are more
efficent way to do it.
and one more thing, in case 3, T1 and T2 needs to lock the socket?, two
threads access same socket description by reading and writing.

"David Schwartz" <davids@webmaster.com> wrote in message
news:dhfnb4$k5t$1@nntp.webmaster.com...
>
> "Ku Jaguk" <jkku@softeleware.com> wrote in message
> news:dhfj8f$s7q$1@news2.kornet.net...
>
>> If the threads doesn't need to lock the same socket description, i think
>> it would be more efficent to have two threads hanle the socket IO,
>> because i useally making a client socket program which has limited
>> connection to server, and i don't like polling the socket.
>
> Using two threads is generally very inefficient because it requires a
> context switch every time you need to change direction. If you have a
> query/response type protocol, then it really hurts you.
>
> DS
>
>

Relevant Pages