Are sockets thread safe
jain...@gmail.com
I am working on Linux environments. The kernal version is 2.4.21 and
my question is;
Are sockets on Linux thread safe. For example if the socke it open and
one thread was
reading from the socket and had to relinquish CPU to make way for
another thread, And
then the other thread is trying to 'Write' to the same socket.
What will be the behavior.
If these libraries are not thread safe then what are my alternatives
1. onLinux
2. on Unix
Thanks for your help.
nagrik
ps: I have read the man pages for sockets and they don't say anything
about thread safety.
Maxim Yegorushkin
jainar...@gmail.com wrote:
> Hello Group,
>
> I am working on Linux environments. The kernal version is 2.4.21 and
> my question is;
>
>
> Are sockets on Linux thread safe. For example if the socke it open and
>
> one thread was
> reading from the socket and had to relinquish CPU to make way for
> another thread, And
> then the other thread is trying to 'Write' to the same socket.
Linux kernel structures are protected by locks so that one can not
screw them up by several threads doing calls on the same socket. You
should care to protect you logic data stream consistency when several
threads operate on the same stream.
Dan N
> Are sockets on Linux thread safe.
Socket read and write are independent operations, it doesn't matter if
they're done in different threads. There are, however, some
idiosyncrasies when it comes to closing them.
Dan
jain...@gmail.com
Dan,
Thanks for your reply. But I am still confused. I understood that
read and write
operations are independent. But what will happen in the following
scenario;
one thread was
reading from the socket and had to relinquish CPU to make way for
another thread,
And then the other thread is trying to 'Write' to the same socket.
In this situation there may be some data in the socket buffer/pipeline
(if there is any),
which is not processed by the read operation because CPU exited the
first thread.
Will the data on socket get corrupted whenn the second thread tries to
write to the
same socket.
There are, however, some
> idiosyncrasies when it comes to closing them.
>
And what you mean with idiosyncrasies, in the event of closing them.
If you could please clarify this.
Thanks
nagrik
jain...@gmail.com
Dan,
I am also confused about two threads writing to same socket at the
concurrently.
Thread 1: write "Hello World"
Thread 2: write "Hello World"
Can the end result on the other side of the socket be
Hel Hello lo Wor World ld.
Similaly if two threads are reading from the same socket the string
specified above
The other end of the socket input is
"Networking code is difficult."
Can the result be as follows
Thread 1: Network
Thread 2: ing co
Thread 1: de is
Thread 2: diff
Thread 1: ic
Thread 2: ult.
And of course the question still remains when two threads are trying to
do simultanious
read and write. What will happen to data at both ends.
Thanks.
nagrik
Phil Frisbie, Jr.
> Dan N wrote:
>
>>On Mon, 12 Jun 2006 13:38:08 -0700, jainarunk wrote:
>>
>>
>>>Are sockets on Linux thread safe.
>>
>>Socket read and write are independent operations, it doesn't matter if
>>they're done in different threads. There are, however, some
>>idiosyncrasies when it comes to closing them.
>>
>>Dan
>
>
> Dan,
>
> I am also confused about two threads writing to same socket at the
> concurrently.
>
> Thread 1: write "Hello World"
>
> Thread 2: write "Hello World"
>
> Can the end result on the other side of the socket be
>
> Hel Hello lo Wor World ld.
If the socket is TCP, then yes, but if the socket is UDP then no.
> Similaly if two threads are reading from the same socket the string
> specified above
>
> The other end of the socket input is
>
> "Networking code is difficult."
>
> Can the result be as follows
>
> Thread 1: Network
> Thread 2: ing co
> Thread 1: de is
> Thread 2: diff
> Thread 1: ic
> Thread 2: ult.
Again, with TCP is is possible, but with UDP it is not.
> And of course the question still remains when two threads are trying to
> do simultanious
> read and write. What will happen to data at both ends.
In most cases it makes no sense to have multiple threads read or writing to a
socket, unless the socket is UDP and you are processing separate messages.
However, as has already been explained, it is possible, and actually common to
have one thread reading from a socket and another writing to the same socket
with no problems.
--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com
Rick Jones
> Thanks for your reply. But I am still confused. I understood that
> read and write operations are independent. But what will happen in
> the following scenario;
> one thread was reading from the socket and had to relinquish CPU to
> make way for another thread,
> And then the other thread is trying to 'Write' to the same socket.
> In this situation there may be some data in the socket
> buffer/pipeline (if there is any), which is not processed by the
> read operation because CPU exited the first thread.
> Will the data on socket get corrupted whenn the second thread tries
> to write to the same socket.
A socket can be considered "full-duplex" in this regard. Inbound and
outbound socket buffers are separate.
rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Dan N
> Thread 1: write "Hello World"
>
> Thread 2: write "Hello World"
>
> Can the end result on the other side of the socket be
>
> Hel Hello lo Wor World ld.
I'm not sure, but I would expect that it wouldn't. I would think that
each thread would finish it's write, but I wouldn't count on it.
>
> Similaly if two threads are reading from the same socket the string
> specified above
>
> The other end of the socket input is
>
> "Networking code is difficult."
>
> Can the result be as follows
>
> Thread 1: Network
> Thread 2: ing co
> Thread 1: de is
> Thread 2: diff
> Thread 1: ic
> Thread 2: ult.
I think that each thread would finish its read before the next thread
started, but, again, I wouldn't count on it.
As someone said in one of the other replies, it doesn't make sense to read
from different threads.
If you want to share data between threads, you're probably better off
using some other method to do so rather than reading from the same socket.
Dan
jain...@gmail.com
Phil,
The need arose, because I am writing a client for a web server, where
each thread in
the client wraps its own request for a paraticular web page from the
server and writes
to the same web server on the other end of the same socket. And of
course each
thread would be interested to read the web page for it sent the
request. I hope it
explains.
Thanks for your reply.
Phil Frisbie, Jr.
> Phil,
>
> The need arose, because I am writing a client for a web server, where
> each thread in
> the client wraps its own request for a paraticular web page from the
> server and writes
> to the same web server on the other end of the same socket.
Why use the same socket? You are making your client GREATLY more complex, just
to save a few sockets from being created? The complexity to keep track of each
response and only let the correct thread read that response will likely lead to
an error prone client that will be very hard to debug.
> And of
> course each
> thread would be interested to read the web page for it sent the
> request. I hope it
> explains.
You have explained WHAT you want to do, but not WHY you have chosen to do it
this way. Perhaps if you explain your needs we can suggest a better way to do it.
Maxim Yegorushkin
jain...@gmail.com wrote:
> Phil,
>
> The need arose, because I am writing a client for a web server, where
> each thread in
> the client wraps its own request for a paraticular web page from the
> server and writes
> to the same web server on the other end of the same socket. And of
> course each
> thread would be interested to read the web page for it sent the
> request. I hope it
> explains.
You need a dispatcher thread that serializes http requests from
different threads and writes them to the socket. This thread or another
one should also read all the http responses from the socket and forward
them to where these responses are waited for.
In any case, there should be no more than one thread simultaneously
reading/writing the same stream socket. Otherwise data get screwed up.
jain...@gmail.com
Maxim Yegorushkin wrote:
> jain...@gmail.com wrote:
>
>
> > Phil,
> >
> > The need arose, because I am writing a client for a web server, where
> > each thread in
> > the client wraps its own request for a paraticular web page from the
> > server and writes
> > to the same web server on the other end of the same socket. And of
> > course each
> > thread would be interested to read the web page for it sent the
> > request. I hope it
> > explains.
>
> You need a dispatcher thread that serializes http requests from
> different threads and writes them to the socket. This thread or another
> one should also read all the http responses from the socket and forward
> them to where these responses are waited for.
Phil, in one of his postings suggested that I have multiple sockets.
My reasoning is that
by having multiple sockets.
1. The user may potentially want to access hundreds of pages and
creating a socket
per page will be very costly and will put undue/unnecessary resource
utilization.
2. Some of the classes in my implementation are private and the 'user'
does not have
access to creatation
3. User is given the responisbility to create the thread and not the
client I am writing.
Because I do not know before hand what would user intend to do.
I will opt for a dispatcher thread solution, because it looks more
promising. However I
will need some guide lines as to how to implement a dispatcher thread,
what data
structures I will have to create, the communication channel between
individual threads
and the dispatcher thread, and the performance cost analysis if any.
Thanks for your support and enlightened discussion.
>
> In any case, there should be no more than one thread simultaneously
> reading/writing the same stream socket. Otherwise data get screwed up.
I was implementing locks and condition variables to ensure that data
does not
corrupted.
Nagrik
Phil Frisbie, Jr.
> Phil, in one of his postings suggested that I have multiple sockets.
> My reasoning is that
> by having multiple sockets.
>
> 1. The user may potentially want to access hundreds of pages and
> creating a socket
> per page will be very costly and will put undue/unnecessary resource
> utilization.
Creating sockets is not very expensive, in either time or memory. A Windows NT
based OS can easily create tens of thousands of TCP sockets if you have at least
256 MB of memory.
Phil Frisbie, Jr.
> jain...@gmail.com wrote:
>
>> Phil, in one of his postings suggested that I have multiple sockets.
>> My reasoning is that
>> by having multiple sockets.
>>
>> 1. The user may potentially want to access hundreds of pages and
>> creating a socket
>> per page will be very costly and will put undue/unnecessary resource
>> utilization.
>
> Creating sockets is not very expensive, in either time or memory. A
> Windows NT based OS can easily create tens of thousands of TCP sockets
> if you have at least 256 MB of memory.
Sorry, I forgot what group I was reading. A Linux app can easily create 1000 or
more sockets as long as you increase the file handle per process limit.
Rick Jones
> 1. The user may potentially want to access hundreds of pages and
> creating a socket per page will be very costly and will put
> undue/unnecessary resource utilization.
Why socket per page? Why not socket per thread? Of course, why
multiple threads in the first place again?
rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
Maxim Yegorushkin
jain...@gmail.com wrote:
[]
> I will opt for a dispatcher thread solution, because it looks more
> promising. However I
> will need some guide lines as to how to implement a dispatcher thread,
> what data
> structures I will have to create, the communication channel between
> individual threads
> and the dispatcher thread, and the performance cost analysis if any.
You may like reading http://www.kegel.com/c10k.html