Re: [Boost-users] Threads Don't Take Turns Under Linux (Ubuntu Gutsy Gibbon)

From: Hal Vaughan (hal_at_[hidden])
Date: 2008-03-17 11:17:59

Zeljko Vrba wrote:

> On Mon, Mar 17, 2008 at 09:42:46AM -0400, Hal Vaughan wrote:
>> 
>> Am I doing something wrong or is there a setting I need to change?
>> 
> That's normal behavior; threads are scheduled by the OS.  In your case,
> the thread fills the buffer faster then its timeslice expires, so you
> see buffer being filled/emptied in "batches".  If you want them to be
> interleaved, lower the buffer size or try running on an SMP machine.

So when I did just a loop in a routine that printed numbers 1-10 (or, when I
experimented, 1-1000), and thread 1 always finished completely before
thread 2 could start, is that the same?  Is there any way I can get the two
threads to run concurrently?  (I know true multi-tasking on a single CPU is
just slicing up time, but by concurrently, I mean sharing resources instead
of one taking up everything.)

This is just a test program, but my big concern is that the program I'm
writing does something like this.  I'm controlling an HD radio through the
serial port (or a usb port with a usb->RS232 adaptor).  I know once I
mention ports, I'm getting into OS specific stuff, but even beyond that
issue, I'm trying to understand what I need to do and what's going on.

When I'm done, I want to have one thread that listens to the port and uses
all the incoming data to check things like the current station, track
title, artist name, and so on.  To read the port this way, I'm using an
ifstream object to open the port as a file, which seems to work well
because it's buffered.  Then, in another thread, I write the commands to
the port as a "regular" file.

This all goes in a library where the listening thread can be started and
stopped.  I don't want to miss incoming data on the ifstream object, but it
seems if I let that thread run on it's own, the other thread to pass on
commands won't get CPU time to run and any program using this lib will be
locked up as long as I'm listening to the port.

I know in Perl I can fork and have one thread continue to do it's own thing
without it seeming to effect the other.  I also know Perl is a much higher
level language, but I was hoping there might be a way, in C++, to spin off
this listener thread, let it keep listening and processing the data, and
have it stay in the background so other threads can continue.

If I can't do that, then I have to write this part of the program as some
kind of daemon so it gets it's own process id and stays separate from the
main program.

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.)

Thanks for any help on this, links for where to look for more info, and so
on!

Hal