«

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?

writes:
> 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.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 2012-09-21, <> wrote:
> 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.

Op vrijdag 21 september 2012 20:59:15 UTC+2 schreef Kaz Kylheku het volgende:
> On 2012-09-21, mic...@gmail.com <mic...@gmail.com> wrote:
>
> > 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.

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