|
Home > Archive > Unix Programming > September 2005 > socket lock in multithred programming
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
socket lock in multithred programming
|
|
| Ku Jaguk 2005-09-28, 7:58 am |
| Hi there,
I am making a multithreaded process.
it has a tcp/ip socket and two threads, one thread for sending message to
socket, the other for receiving a message from socket. i don't know it's a
good architecture or not for socket programming.
the question is
1. Does it need to lock(for example mutex lock) the socket in both threads
whenever sending to and receiving from socket?
2. If it need to lock the socket, why?
3. If it doesn't need to lock the socket, why?
4. If it doesn't need to lock the socket, which thread should close the
socket? if one thread close the socket and set socket fd with -1 value
without locking it, what happend to the other thread when it access the
socket fd?
5. If it need to lock the socket, i think i don't need to make two threads,
just one thread is ok. am i right?
thanks in advance
Jaguk Ku
| |
| Pascal Bourguignon 2005-09-28, 7:58 am |
| "Ku Jaguk" <jkku@softeleware.com> writes:
> Hi there,
>
> I am making a multithreaded process.
> it has a tcp/ip socket and two threads, one thread for sending message to
> socket, the other for receiving a message from socket. i don't know it's a
> good architecture or not for socket programming.
>
> the question is
> 1. Does it need to lock(for example mutex lock) the socket in both threads
> whenever sending to and receiving from socket?
>
> 2. If it need to lock the socket, why?
>
> 3. If it doesn't need to lock the socket, why?
>
> 4. If it doesn't need to lock the socket, which thread should close the
> socket? if one thread close the socket and set socket fd with -1 value
> without locking it, what happend to the other thread when it access the
> socket fd?
>
> 5. If it need to lock the socket, i think i don't need to make two threads,
> just one thread is ok. am i right?
Sounds like homework.
Try reading some more man pages and course material.
Start with:
man 2 socket
man 7 socket
man 2 close
and some tutorial about unix, processes, file descriptors and
threads. (Use google).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Small brave carnivores
Kill pine cones and mosquitoes
Fear vacuum cleaner
| |
| Ku Jaguk 2005-09-29, 2:55 am |
| First, it's not the homework.
I used to make a socket program, even multithreaded socket program and i
have read enough books about the socket i think.
Even Stevens book socket programming, I don't think it mentions about one
thread only reading to and the other thread only writing from the same
socket descriptor.
I have tried all the case of socket server processes in real environment
those are mentioned in Stevens socket programming 1, such as single process
server, dynamic fork, pre-fork, dynamic spawning thread, pre-threaded, even
i anylized the current Apache web server, Hybrid multithreaded socket which
has pre-fork and pre-thread.
you said i should look at the socket man page, i just read all man pages but
i can not find about it.
I am sincerely saying that i can not find about what i mentioned. and i
really curious about it.
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.
Thanks in advance,
Jaguk Ku
"Pascal Bourguignon" <spam@mouse-potato.com> wrote in message
news:871x39gxq5.fsf@thalassa.informatimago.com...
> "Ku Jaguk" <jkku@softeleware.com> writes:
>
>
> Sounds like homework.
>
> Try reading some more man pages and course material.
> Start with:
>
> man 2 socket
> man 7 socket
> man 2 close
>
> and some tutorial about unix, processes, file descriptors and
> threads. (Use google).
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> Small brave carnivores
> Kill pine cones and mosquitoes
> Fear vacuum cleaner
| |
| David Schwartz 2005-09-29, 2:55 am |
|
"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
| |
| Ku Jaguk 2005-09-29, 2:55 am |
| 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...
>
>
> 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
>
>
| |
| Pascal Bourguignon 2005-09-29, 7:52 am |
| "Ku Jaguk" <jkku@softeleware.com> writes:
> First, it's not the homework.
>
> I used to make a socket program, even multithreaded socket program and i
> have read enough books about the socket i think.
> Even Stevens book socket programming, I don't think it mentions about one
> thread only reading to and the other thread only writing from the same
> socket descriptor.
> I have tried all the case of socket server processes in real environment
> those are mentioned in Stevens socket programming 1, such as single process
> server, dynamic fork, pre-fork, dynamic spawning thread, pre-threaded, even
> i anylized the current Apache web server, Hybrid multithreaded socket which
> has pre-fork and pre-thread.
>
> you said i should look at the socket man page, i just read all man pages but
> i can not find about it.
>
> I am sincerely saying that i can not find about what i mentioned. and i
> really curious about it.
>
> 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.
If you need full-duplex communication, yes.
[vbcol=seagreen]
No.
[vbcol=seagreen]
Mu.
[vbcol=seagreen]
Because unix can multiplex all I/O.
For the kernel, two threads one reading, the other writing to the same
file is the same as two processes, one reading the other writing to
the same file.
[vbcol=seagreen]
Any one.
You still need to do some more reading about unix,
and about threads (vs. processes).
You must distinguish kernel space structures from user space structures.
A file descriptor is a handle for a kernel space structure.
When you write "set socket fd with -1", you're speaking about a user
space variable, and threads DO share ALL user space variables, as well
as they share the kernel space structure, when they belong to the same
process.
So, when you close from a process a file descriptor, it's close,
point. If you try to close it again, (or do any other I/O on it) you
get an error. It doesn't matter from which thread you call close(2).
That said, you could duplicate the file descriptor, to access
independently twice (or more) to the same file using dup(2) or
dup2(2). If you wanted to close from one thread and go on with the
other, you could duplicate file descriptors to give one to each
thread.
[vbcol=seagreen]
You don't need to lock, but if your protocol is query/response, you
don't need two thread either.
Only if you wanted to send, let's say 100KB from A to B, and 100KB
from B to A, at the same time would it be worthwile to use two
threads.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Litter box not here.
You must have moved it again.
I'll poop in the sink.
| |
| David Schwartz 2005-09-29, 6:00 pm |
|
"Ku Jaguk" <jkku@softeleware.com> wrote in message
news:dhfuer$apm$1@news2.kornet.net...
> I thought case 3 would be OK for me, but i am wondering there are more
> efficent way to do it.
It's hard to say with just the information you've given.
> 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.
I forgot what platform we were talking about, but if it's POSIX pthreads
or Winsock2, you do not need to lock the socket. You can read and write on
the same socket at the same time.
DS
|
|
|
|
|