simultaneously read and write on one socket file

[Pallav singh]

Hi ,

Assume a tcp/ip connection between two Linux platforms established via
the socket interface. The processes on the two platforms communicate
through a file descriptor.

Is it possible to simultaneously read and write on one socket file
descriptor from 2 threads within the process, i.e. one thread reads
data the other thread writes data at the same time on the same file
descriptor ?

Or will this screw up my data ?

Thanks
Pallav Singh

 

[Richard Herring]

In message

tcp/ip
Linux
socket interface.
file descriptor.

ISO 14882 has no knowledge of these terms. Are you sure you're posting
in the correct newsgroup?

 

[cr88192]

Hi ,

Assume a tcp/ip connection between two Linux platforms established via
the socket interface. The processes on the two platforms communicate
through a file descriptor.

Is it possible to simultaneously read and write on one socket file
descriptor from 2 threads within the process, i.e. one thread reads
data the other thread writes data at the same time on the same file
descriptor ?

Or will this screw up my data ?

I guess the topic police wont like this topic...

but, anyways, "it depends", better would be to "play it safe" and use a
mutex.

FWIW, it is further an issue if one is using blocking IO (vs blocking IO),
as AFAIK Linux's mutex'es are of "agressive" variety (AKA: whenever
competing for a lock, there will be a spike in CPU load (as one thread tries
repeatedly to lock the mutex, while the other thread sleeps on IO), meaning
they are not good for locks which are likely to be held for a period of
time).

in this case (I forget the details as to how to pull it off on Linux), it is
possible to get the waiting thread to sleep and then wake it back up again
once notified (this is more how the WIN32 API's "mutex objects" work AFAIK,
but it is not free as locking/unlocking is slow), thus no 100% CPU load as
the other thread waits for the mutex to release...

 

[Ron AF Greve]

Hi,

A possibility is to write some code to buffer sending/receiving. Then when a
process tries to sent it just writes to the buffer (same for read). Then use
'select' to listen and read/write on a set of descriptors in a separate
thread to do the actual reading/writing between socket and buffers. (This is
actually how I handle it under MS-Windows.

I also use one socket to control the whole thing. For instance the class has
an interface to add a socket. However there must be a way to trigger the
select to fall out (you could let it fall out of the select every x
microseconds of course, that would be another way). So the member function
adds the socket to the list and writes a command to the 'control' socket.
The select completes and can then add the new socket to the list and start
the select again.


Regards, Ron AF Greve

http://informationsuperhighway.eu

 

[James Kanze]

Assume a tcp/ip connection between two Linux platforms
established via the socket interface. The processes on the two
platforms communicate through a file descriptor.

Is it possible to simultaneously read and write on one socket
file descriptor from 2 threads within the process, i.e. one
thread reads data the other thread writes data at the same
time on the same file descriptor ?

Or will this screw up my data ?

This has nothing to do with C++; you should ask in
comp.unix.programmer. But the simple answer is that there is no
problem, and it's the usual solution. Posix guarantees it.

 

[James Kanze]

I guess the topic police wont like this topic...

It's obviously posted to the wrong group.

but, anyways, "it depends", better would be to "play it safe"
and use a mutex.

Which is a nice way to get your process to hang.

FWIW, it is further an issue if one is using blocking IO (vs
blocking IO), as AFAIK Linux's mutex'es are of "agressive"
variety (AKA: whenever competing for a lock, there will be a
spike in CPU load (as one thread tries repeatedly to lock the
mutex, while the other thread sleeps on IO), meaning they are
not good for locks which are likely to be held for a period of
time).

If that's the case, it's time to change systems. There will be
a (very short) spike when the a process attempts to acquire a
locked mutex, and is suspended. After that, both processes
should be sleeping, and taking 0% CPU. (The problem, of course,
is that both are sleeping, so nothing happens.)

in this case (I forget the details as to how to pull it off on
Linux), it is possible to get the waiting thread to sleep and
then wake it back up again once notified (this is more how the
WIN32 API's "mutex objects" work AFAIK, but it is not free as
locking/unlocking is slow), thus no 100% CPU load as the other
thread waits for the mutex to release...

It's possible to do what he want from a single thread, with no
locks, by polling on input: the process puts a relatively short
timeout on the input, and when woken up because of the time out,
checks to see if there is anything to send, and sends it. Using
two separate threads is cleaner.

 

[James Kanze]

A possibility is to write some code to buffer
sending/receiving. Then when a process tries to sent it just
writes to the buffer (same for read). Then use 'select' to
listen and read/write on a set of descriptors in a separate
thread to do the actual reading/writing between socket and
buffers. (This is actually how I handle it under MS-Windows.

That's the third solution. The reader thread does a select
on the socket and a pipe. When the writer thread has something
to write, it writes something to the pipe, waking up the reader
thread, which then does the actual write.

There's no need for such additional complexity on a Posix
compliant system; I'd be somewhat surprised if Windows required
it as well.