discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Comments on "BBN's Proposed extensions for data n


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Comments on "BBN's Proposed extensions for data networking"
Date: Wed, 7 Jun 2006 23:01:07 -0700
User-agent: Mutt/1.5.9i

On Thu, Jun 08, 2006 at 12:38:02AM -0400, David Lapsley wrote:
> 
> >* p60, 4.8.1: "In order to support real-time scheduling, a mechanism is 
> >required that will allow m-block s to relinquish control of a processor 
> >after a certain number of processor cycles have been used (we will refer 
> >to this number of processor cycles as the scheduling quantum )." and 
> >"The gr single threaded scheduler will run until it walks all the 
> >incoming data (one scheduling quantum worth) through the graph to the 
> >final sink, at which point it returns."
> 
> I believe these two statements are consistent.  The two cases are:
> 
> * A generic m-block (no GNU Radio blocks inside it):  in this case, the 
> 
>   processing inside the m-block must relinquish control of the processor
>   after "quantum" processor cycles.
> 
> * An m-block enclosing a GNU Radio flow graph: in this case, the
>   enclosing m-block will pass a block of data that should take one
>   quantum's worth of processor cycles to pass through the GNU Radio flow
>   graph.
> 
> In either case, the m-block is relinquishing processor control after one 
> quantum's worth of cycles.
> 
> >--> These seem in conflict with each other.  Further, the only obvious 
> >reference in 4.8.2 to the relinquishing of control is the "yield()" 
> >function.  Maybe: The "gr single threaded scheduler" is run in a 
> >separate thread from the executing m-block, and the m-block sleeps for a 
> >set time (the "scheduling quantum") ... it will wake up if the thread 
> >finishes or if the sleep returns, at which point it checks the state of 
> >the thread, and either yields to the m-scheduler, or returns the 
> >gr-scheduler's data.
> 
> Yes.  The "gr single threaded scheduler" runs in its own thread.  The 
> sequence you suggest should work just fine.

Nope.  gr_single_threaded_scheduler (or something above it) will be
called from the handle_message callback of the mblock, and thus will
execute on the mblock's thread.

FWIW, I think all this stuff about scheduler quanta is confusing, and
should be deleted.  I'm assuming that everything is "run to completion".
If you want a shorter interval until completion, bite off smaller
chunks.  I don't think any of this really needs to be in the doc, but
will fall out as an implementation detail.

Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]