Home/Support/Support Forum/Blocking sockets
New and improved user forum site going live on 12/6 (All users will need to reset their password when the new forum is active)
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Blocking sockets

0 votes
While read() is blocking and waitting data from the socket is there any problems to write() the same socket from another thread at the same time?

I tried it and it seems that it's ok but if anybody knows that this is not ok please educate me.
asked Jun 8, 2007 in NET+OS by cm New to the Community (8 points)
recategorized Dec 4, 2013 by tuxembb

Please log in or register to answer this question.

25 Answers

0 votes
NET+OS will only allow one thread at a time to have control of the serial driver. I.E. if one thread is doing a blocking read/write, and a second thread comes in, it should be returned an access error.
answered Jun 10, 2007 by charliek Veteran of the Digi Community (408 points)
0 votes
Charlie is right, but you can easily get around that by using the tc() functions. Don't wait for a char, just ask if one is in the buffer.

-Erik

=========================================
struct serial_buffer_t sbt;
tcgetbuffers(fds, &sbt);

if( sbt.rxbuf > 0 )
{
read(fds, buf, _countof(buf));
}
answered Jun 12, 2007 by egawtry Veteran of the Digi Community (349 points)
0 votes
That's strange, because I have a thread permanently reading one character from serial port (sets an event when received and loops back to read) and I am writing to same serial port from other thread with no problem!
answered Jun 12, 2007 by Adrian New to the Community (46 points)
0 votes
Thank you very much for the answers.

But I mean reading and writing from/to sockets (TCP/IP)?
answered Jun 17, 2007 by cm New to the Community (8 points)
0 votes
If you're using send() and recv() to talk to a socket, you can do so from multiple threads, but these are not thread safe, so you will want to use a Mutex or Semaphore. Similar to what Erik posted, you can use select() to determine if you need to read from the socket before actually calling recv().
answered Jun 18, 2007 by charliek Veteran of the Digi Community (408 points)
0 votes
I have a thread which is in blocking recv() and another is writing by the write().

This is working for me without any errors (or do they come in stage later...?!)

So you mean that the recv() and write() functions itself for the socket is not a thread safe for example I cannot call write() from multiple threads at the same time without using semaphores but I can call write() from one thread and recv() from another at the same time as my example code is showing me.

Right?
answered Jun 19, 2007 by cm New to the Community (8 points)
0 votes
I mean I am writing the socket by the send() command and reading by the recv()...
answered Jun 19, 2007 by cm New to the Community (8 points)
0 votes
While it is supposedly fixed in NetOS 7, all the network functions are unsafe to simultaneously use in more than one thread at a time in 6.x. In other words, don't call send(), recv(), or select() at the same time from two different threads.

I posted a patch for this a while ago.

http://www.digi.com/support/forum/viewthread_thread,1408#5227
answered Jun 19, 2007 by egawtry Veteran of the Digi Community (349 points)
0 votes
Ok.

Im using 7.1 and as I said it seems to work ok. I can use send() without any errors while another thread is in blocking recv().

Just asked this to solve out is there any known "hidden problems" which comes out later if used like this...
answered Jun 19, 2007 by cm New to the Community (8 points)
0 votes
I'm not sure when select was fixed, but it definately is working properly in multiple threads in NET+OS 7.1. However, sockets, are not thread safe when accessed from multiple threads at the same time. You do need to semaphore or mutex protect them.
answered Jun 19, 2007 by charliek Veteran of the Digi Community (408 points)
...