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

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

Zeljko Vrba wrote:

> On Mon, Mar 17, 2008 at 11:17:59AM -0400, Hal Vaughan wrote:
>> 
>> 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
>>
> Yes, you need to properly synchronize between them.  Thread A has to
> explicitly signal thread B to start running (while A puts itself to
> sleep). If you don't use such signalling, the OS has all right to assume
> that you don't care about the scheduling order.

So there's nothing I can use to try to split time evenly between them?

>>
>> just slicing up time, but by concurrently, I mean sharing resources
>> instead of one taking up everything.)
>> 
> "Sharing resources" is very vaguely defined.  If thread A runs for 30
> seconds, and then B for 30 seconds without interruption, they will still
> have received their fair share of resources if the total run time of the
> program is, say, 1 hour.
> 
>> 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.
>> 
> 
>>
>> 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
>>
> Using buffered I/O with external devices is a bad idea, IMHO.

I've had several people comment on that while I've been seeking help on
this, but that's the way it seems to work best (as opposed to just opening
the serial port and reading it directly) and nobody's told me why it's a
bad idea.  If the port gets extra data while I'm doing something else,
won't it store in the buffer?

>> 
>> 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
>>
> The thread won't be running on its own if there's no data - it'll go to
> sleep and other threads will be scheduled.
> 
>> 
>> 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
>>
> I don't think that Perl's threads are "real" OS-threads.

I don't think so either, but the advantage is that it has some kind of
system for managing them.  I don't know how complex or simple it is, but I
was hoping there might be something more automatic I can use in this case.

>> 
>> 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
>>
> Well, yes, threads sleep on I/O when I/O is not possible at the given
> moment.

That may help, but in the long run, there are people that might be using
this in connection with a GUI.  How do I make sure my stuff doesn't take up
all the resources?  Or is that partly the GUI programmer's job?  To split
things into threads on their end to keep the UI updated?

Hal