Basic thread questions
- From: Zerex71 <mfeher1971@xxxxxxxxx>
- Date: Wed, 29 Oct 2008 09:41:27 -0700 (PDT)
Hi group,
I am writing a m/t application at work that basically deals with
several software-hardware interfaces. As one example, when the box
(Linux RHEL 5.1 in a ruggedized form factor) reads data from an RS-422
(serial) port from another box, it then converts the data into UDP
datagrams to be sent on to yet a third device. In my app, I have a
listener thread which pulls from the RS-422 card and interprets the
raw data coming in.
Now what I have discovered is in a test box which is driving my
RS-422, if I don't throttle the messaging, the test box (a PC with an
MFC app constantly throwing out 422 data) overwhelms my app and,
despite the fact that every one of my worker threads ends its while
loop with a sleep of equal duration (on the theory that sleep both
delays its return and yields to the next thread in line), another
thread which processes the incoming data and converts it to UDP
messages still gets hung up. For example, if the test box has a sleep
of 1ms, it slams my box with data so much that my 422-to-UDP thread
gets backlogged to the tune of several thousand messages.
When I adjust the test app's sleep to a 500ms delay, things are
considerably more calmed down and the 422-to-UDP thread is able to
keep up with the incoming data.
So my questions are,
1. Is there a way to mitigate this problem if on a real 422 box I'm
not able to adjust the data rate coming out?
2. Does sleep() actually wait the duration (I believe it does) AND
yield to other threads?
3. Is there a way to adjust thread priorities if need be if, in the
real system, I find that no matter what I do, having equal thread
priorities give me problems?
I should clarify by saying that our particular RS-422 interface
operates at a rate of 38.4 kHz but I have no idea the real rate that
test messages are being produced by the test box to send, i.e. I
assume it's on the order of 2 Hz with a 500ms delay and 1 kHz with a
1ms delay.
Thanks,
Mike
.
- Follow-Ups:
- Re: Basic thread questions
- From: David Schwartz
- Re: Basic thread questions
- From: Eric Sosman
- Re: Basic thread questions
- Prev by Date: Re: Examples of performance threading applications
- Next by Date: Re: Basic thread questions
- Previous by thread: Lock-free ring buffer memory barriers test case
- Next by thread: Re: Basic thread questions
- Index(es):
Relevant Pages
|