# Block processing order

**URL:** <https://www.ruby-forum.com/t/block-processing-order/179903>\
**Category:** GNU Radio\
**Created:** [December 7, 2009, 8:26pm UTC](https://www.ruby-forum.com/t/block-processing-order/179903 "2009-12-07T20:26:38Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![hailandkill](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/f4b2a3/32.png) [@hailandkill](https://www.ruby-forum.com/u/hailandkill)\
**Post date:** [December 7, 2009, 8:26pm UTC](https://www.ruby-forum.com/t/block-processing-order/179903/1 "2009-12-07T20:26:38Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![hailandkill](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/f4b2a3/32.png) [@hailandkill](https://www.ruby-forum.com/u/hailandkill)\
**Post date:** [December 7, 2009, 9:23pm UTC](https://www.ruby-forum.com/t/block-processing-order/179903/2 "2009-12-07T21:23:59Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![hailandkill](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/f4b2a3/32.png) [@hailandkill](https://www.ruby-forum.com/u/hailandkill)\
**Post date:** [December 8, 2009, 2:33am UTC](https://www.ruby-forum.com/t/block-processing-order/179903/3 "2009-12-08T02:33:04Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![hailandkill](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/f4b2a3/32.png) [@hailandkill](https://www.ruby-forum.com/u/hailandkill)\
**Post date:** [December 8, 2009, 12:48pm UTC](https://www.ruby-forum.com/t/block-processing-order/179903/4 "2009-12-08T12:48:13Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![hailandkill](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/f4b2a3/32.png) [@hailandkill](https://www.ruby-forum.com/u/hailandkill)\
**Post date:** [December 8, 2009, 6:41pm UTC](https://www.ruby-forum.com/t/block-processing-order/179903/5 "2009-12-08T18:41:09Z")

</div>

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