Boost logo

Boost Users :

From: Hal Vaughan (hal_at_[hidden])
Date: 2008-03-17 12:42:07


Stephen Nuchia wrote:

>
>> So is there no way to create a thread and not have it take up all the
> CPU
>> time until it's done without using SMP? (This is going to be for
>> carputers, so it won't be in an SMP environment.)
>
> Now that you've clarified your intended purpose, it is apparent that
> your simple producer/consumer test program was not a good model of the
> real program.

I'm beginning to see that, mainly because, as I read the posts, I'm
realizing that there are a lot of low-level issues that I hadn't expected.
I'm used to Perl or Java where all that is taken care of. Back in the
1980s I used to program in Assembler and deal with low level issues, but
that was on a 6502 (Apple //e), so I never dealt with any issues in terms
of threading.

> How the threaded serial port monitor will work in your production
> environment is something you'll have to experiment with. If the target
> environment has good support for threads and a fairly high-level driver
> for the serial port then simply assigning a higher priority to the port
> monitor thread should work. But it may be necessary to use an
> interrupt-based solution instead.

I was (and still am) hoping it doesn't get to dealing with interrupts.
That's a whole different topic and I'm quite new to C++. This kind of
programming for me, in any language, is rare. I hardly ever have to deal
with the hardware issues. In this case, I didn't realize how important
waiting on the serial port could be.

> The normal paradigm for threads on a uniprocessor is that the
> highest-priority runnable thread runs until it is no longer the
> highest-priority runnable thread. That can happen when
> 1) It blocks, either for I/O or on a mutex or
> 2) The priority of that thread or another thread is changed or
> 3) Some higher-priority thread becomes runnable (I/O completes,
> interrupting event occurs, or mutex freed).
> 4) If more than one thread is runnable at the highest priority, the
> system may time slice among them at some fairly low frequency (10-1000
> ms typically).
> 5) In non-realtime unix environments, such as the one in which you are
> experimenting, there is a dynamic priority adjustment scheme at work
> that is designed to give good interactive responsiveness under load.
> This scheduler protocol is often not suitable for realtime applications.

By non-real time, you mean the demo program, right?

> Time slicing more frequently would impact efficiency because the context
> switch itself takes time and the new thread will want a different
> working set in the cache, leading to a lot of unnecessary memory
> traffic. You may want to pay that price for simulation purposes but in
> general you don't want it. See others' comments about inserting sleep
> commands if you want to simulate multiprocessor behavior.

After looking over what I've learned (and thanks to all, because this thread
on threads has been an education in itself), I don't think the threads and
timing will be an issue because the one reading from the serial port will
be blocked most of the time (it never seems to get more than 256 bytes at a
time and rarely more than 40 at a time) and when it isn't, I can use
nanosleep as it processes to make sure it never hogs resources. That
should make that thread almost invisible in terms of the time it consumes.
(Is my reasoning right on that?)

> Ideally, your production program's port monitor thread would run at high
> priority but spend most of its time blocked waiting for input. When a
> frame becomes available the hardware should interrupt the driver,
> leading to your thread becoming runnable. When the OS returns from the
> driver's interrupt service routine your input thread should then run
> until it loops back to wait for more input. If you haven't signaled any
> semaphores the previously running thread resumes at that point. If you
> did signal data available a different thread may be scheduled.

I don't need to signal data available, at least as far as I know. I may by
simply changing a boolean flag.

> I've built several systems on this principle very successfully but you
> have to know your OS and compiler and hardware cold to get reasonable
> performance and reliability.

That's the hard part. This is working at a low level I haven't worked at
for about 20 years and when I did, there was no multi-tasking and no issues
like this. (Sometimes I still year for days when I was working on simpler
8 bit systems!)

Hal


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net