pthread and serial port

[micro.q]

Hi,

I'm creating a shared object which communicates with an serial device. I have some functions which will called when that type of data is required, forexample the battery voltage. The application also needs to monitor any faults on the device, this must be done by polling. I use pthread mutexes around the serial functions.
Now my application has a separate thread for polling. But this causes faults in the data read from the serial device. Is it correct that this is because of the multithreading? Or should this function normaly?

What would be a good solution:
1) Create separate thread which reads all the data and store these in a struct or something. Functions reads the structs instead of serial port.
2) Communication between the functions and the thread which communicates with the serial port.
- Any other good solutions?

 

[Keith Thompson]

I'm creating a shared object which communicates with an serial
device. I have some functions which will called when that type of data
is required, for example the battery voltage. The application also
needs to monitor any faults on the device, this must be done by
polling. I use pthread mutexes around the serial functions. Now my
application has a separate thread for polling. But this causes faults
in the data read from the serial device. Is it correct that this is
because of the multithreading? Or should this function normaly?

What would be a good solution:
1) Create separate thread which reads all the data and store these in
a struct or something. Functions reads the structs instead of serial
port.
2) Communication between the functions and the thread which
communicates with the serial port.
- Any other good solutions?

The new C standard does support threading, but you appear to be
using POSIX-style threads, which are similar but not identical
to the new C11-style threads. I suggest that you'll get better
answers in either comp.unix.programmer or comp.programming.threads.

 

[Kaz Kylheku]

Now my application has a separate thread for polling. But this causes faults
in the data read from the serial device. Is it correct that this is because
of the multithreading? Or should this function normaly?

No, it's because you have a bug in your program. Of course threads can be used
to read from serial ports.

What would be a good solution:
1) Create separate thread which reads all the data and store these in a struct or something. Functions reads the structs instead of serial port.

Your serial driver already does the same thing. You achieve nothing by
repeating it. There is no advantage in those threads reading the structs
instead of the serial port.

The best way to use a threads for input is to have that thread perform the
input, and then in that same thread, so the processing of that input.
The processing code should be executable by any thread, rather than
a decidated thread.

2) Communication between the functions and the thread which communicates with
the serial port.

This is not different from 1 in any fundamental way. Communication means
putting data into structures that another thread reads.

- Any other good solutions?

Use one thread to write a single event loop based on polling descriptors
with poll or select. Then you don't have to debug multithreading problems.

 

[micro.q]

Op vrijdag 21 september 2012 20:59:15 UTC+2 schreef Kaz Kylheku het volgende:

No, it's because you have a bug in your program. Of course threads can be used

to read from serial ports.







Your serial driver already does the same thing. You achieve nothing by

repeating it. There is no advantage in those threads reading the structs

instead of the serial port.



The best way to use a threads for input is to have that thread perform the

input, and then in that same thread, so the processing of that input.

The processing code should be executable by any thread, rather than

a decidated thread.







This is not different from 1 in any fundamental way. Communication means

putting data into structures that another thread reads.






Use one thread to write a single event loop based on polling descriptors

with poll or select. Then you don't have to debug multithreading problems.

Thank you for the answers, indeed it was a bug. I had to sleep between sending commands because the device required that.