Unix Programming - select() and multi-threading

Author

select() and multi-threading

Robert Latest

2006-06-22, 7:25 am

I'm writing an app that does some writing to and reading from an
external device. Since I don't know when data comes in, I'd like to do
the reading in a separate thread which accumulates data in a queue to be
processed by the main application whan it has time.

I've got this working now, but the reading and writing of the file
descriptor is in no way synchronized -- the "listener" thread simply
blocks on a read() until some data comes in, then puts it in the queue.

My hunch is that this will eventualy break because of a collision of a
read() and write() from the two threads.

Question 1: Can it?

On the assumption that it can, I thought about letting the "listener"
block on a select() on the fd, lock a mutex when select() returns, do
the read() and unlock the mutex when finished. Of course the write() in
the other thread is protected by the same mutex.

Question 2: Is this safe, or are there still collisions possible
(between write() and select())?

Question 3: How would you do it?

Thanks,
robert

Maxim Yegorushkin

2006-06-22, 1:27 pm

Robert Latest wrote:
> I'm writing an app that does some writing to and reading from an
> external device. Since I don't know when data comes in, I'd like to do
> the reading in a separate thread which accumulates data in a queue to be
> processed by the main application whan it has time.
>
> I've got this working now, but the reading and writing of the file
> descriptor is in no way synchronized -- the "listener" thread simply
> blocks on a read() until some data comes in, then puts it in the queue.
>
> My hunch is that this will eventualy break because of a collision of a
> read() and write() from the two threads.
>
> Question 1: Can it?
>
> On the assumption that it can, I thought about letting the "listener"
> block on a select() on the fd, lock a mutex when select() returns, do
> the read() and unlock the mutex when finished. Of course the write() in
> the other thread is protected by the same mutex.
>
> Question 2: Is this safe, or are there still collisions possible
> (between write() and select())?

This question has been answered recently here
http://groups.google.com/group/comp...a8c7a03acfa1d18
(show option -> view thread)

> Question 3: How would you do it?

Learn more about IO strategies
http://www.kegel.com/c10k.html#strategies
Use nonblocking IO. Do reading and writing in the same thread.

Robert Latest

2006-06-23, 7:32 am

On 22 Jun 2006 07:59:08 -0700,
Maxim Yegorushkin <maxim.yegorushkin@gmail.com> wrote
in Msg. <1150988348.051416.164100@g10g2000cwb.googlegroups.com>

> This question has been answered recently here
> http://groups.google.com/group/comp...a8c7a03acfa1d18
> (show option -> view thread)
>
>
> Learn more about IO strategies
> http://www.kegel.com/c10k.html#strategies
> Use nonblocking IO. Do reading and writing in the same thread.

Thanks for the links, that helps a great deal.

A related question: Because these issues mostly arise in networking
applications, people mostly talk about socket I/O. Is it valid more
generally for any kind of I/O?

Thanks,
robert

Maxim Yegorushkin

2006-06-23, 7:32 am

Robert Latest wrote:
> On 22 Jun 2006 07:59:08 -0700,
> Maxim Yegorushkin <maxim.yegorushkin@gmail.com> wrote
> in Msg. <1150988348.051416.164100@g10g2000cwb.googlegroups.com>
>
>
> Thanks for the links, that helps a great deal.
>
> A related question: Because these issues mostly arise in networking
> applications, people mostly talk about socket I/O. Is it valid more
> generally for any kind of I/O?

Could you please elaborate?

Robert Latest

2006-06-26, 1:22 pm

On 23 Jun 2006 04:16:23 -0700,
Maxim Yegorushkin <maxim.yegorushkin@gmail.com> wrote
in Msg. <1151061383.330674.33880@g10g2000cwb.googlegroups.com>

>
> Could you please elaborate?

What I mean is: On Unix system, every I/O operation (networking,
filesystem, other hardware) works through the filesystem by using
read/write/select... on file handles. All information that I could find
which deals with thread safety, timing etc. only specifically menations
socket I/O because it is network oriented.

In my app, I'm communicating with an external hardware (an old INMOS
transputer system) through a file descriptor which AFAIK is not a
socket.

I was wondering if the satements made about socket I/O, particularly
about the use of select() and multithreading issues in the links you
provided are valid for any kind of I/O.

Thanks,
robert

Andrei Voropaev

2006-06-27, 7:27 am

On 2006-06-26, Robert Latest <boblatest@yahoo.com> wrote:
[...]
> In my app, I'm communicating with an external hardware (an old INMOS
> transputer system) through a file descriptor which AFAIK is not a
> socket.
>
> I was wondering if the satements made about socket I/O, particularly
> about the use of select() and multithreading issues in the links you
> provided are valid for any kind of I/O.

I guess, this depends on the driver for your hardware. For example,
hard-drive is also a piece of hardware, but you can open the "device", thus
get the file descriptor for it, and then read the content of the disk
and even write to it (possibly corrupting file system on it

In fact networking sockets are deviating from the "file descriptor".
There are functions 'send' and 'recv' that do better work with sockets,
than regular 'write' and 'read'.

So, if the author of the driver for your hardware really wanted it to
work thru the "file descriptor", then you probably can communicate with
it purely thru the descriptor.

(Side note, there's one OS called Plan9. There they try to make sure
that everything appears to be a file, very powerful concept

--
Minds, like parachutes, function best when open