Block processing order

GNU Radio
#1

Hi all,

Does anyone know if the scheduler is guaranteed to process blocks in
the correct order? For example, say you have a block with side
effects such as writing to a file, could it ever occur that the
scheduler is processing several work functions for the same block
concurrently in different threads, the threads execute at a different
rate and you end up with a file written out of order? In a similar
manner is accessing block member variables safe? For example I want
to write a ‘latch’ block that takes in and outputs bits. The output
will be low while the input is low until the first high bit is
received and then the output will remain high until it is reset. If I
store the latch state in a member variable is it guaranteed that when
the latch is triggered at a given sample number all the output sample
before hand will be 0 and all after will be 1?

Many thanks,

Ben G.

#2

Hi Ben,

I was having problems with what appears to be blocks of data being saved
out
of sync (tended to happen at decimation rates lower than 100) but I
haven’t
had a chance to get to the root of this issue, my current line of
thinking
is that when blocks have a side effect the ordering isnt guarenteed.

I modified the USRP2 source to output a second stream of timestamps and
found the problem by running a quick sanity check by saving to disk,
then
importing and checking if each timestamp is higher than the one
preceding
it.
When using a C++ module (rather than a file sink) to check this
everything
seemed to be working as expected hence me thinking that it only occurs
when
the blocks output isnt limited to gnuradio.

I might be completely wrong as I cant seem to find the code for the
multi-threaded scheduler to try and work out whats going on, can anyone
point me in the right direction?

Cheers,

Tim

#3

On Mon, Dec 07, 2009 at 06:18:33PM +0000, Ben G. wrote:

Hi all,

Does anyone know if the scheduler is guaranteed to process blocks in
the correct order?

Yes it does.

For example, say you have a block with side
effects such as writing to a file, could it ever occur that the
scheduler is processing several work functions for the same block
concurrently in different threads, the threads execute at a different
rate and you end up with a file written out of order?

I’m not exactly following this question. There is only a single work
method for a given block. There is only ever a single thread running
the work method of any given instance of a block.

In a similar manner is accessing block member variables safe?

From where? It IS safe from the work methods. It IS NOT safe from
anywhere else.

Eric

#4

Thanks Eric,

My concern was that the scheduler might be creating multiple threads
to process the same work method with different blocks of stream
samples at different point in time. I haven’t managed to locate the
multi-threaded scheduler code yet. The fact that there is only one
thread per work function answers all my questions. However that means
there is another cause of Tim’s problem with saving streams to disk.

Ben

#5

On Tue, Dec 08, 2009 at 11:37:08AM +0000, Ben G. wrote:

Thanks Eric,

You’re welcome.

I haven’t managed to locate the multi-threaded scheduler code yet.

It’s here: gnuradio-core/src/lib/runtime/tpb.{h,cc}

Have fun!

Eric