Re: [Discuss-gnuradio] Scheduler Issues with Branch Prediction

[Ron Sadlier]

Thanks for the responses.

> That should be a clue. The throttle block absolutely works right after
> a file source. It always has in the thousands of cases I've tried and
> seen. <snip>

I'm still having this problem, even after creating the simplest flow
graph possible:

File source -> Throttle (val = 1) -> Terminal Sink.

Terminal sink has the following code:
const unsigned char *inputByte = (const unsigned char *)input_items[0];
std::cerr << (unsigned char)inputByte[0];
consume_each(1);
return 1;

I understand this is not ideal and could be looped for available
items, but this is the simplest I could break the terminal sink down
to. I assume there's something here I'm doing incorrectly, and that's
why it is not working properly? My original flow graph does not use
terminal sink, so it'd have to be a common problem to the other blocks
due to a consistent programming error on my part (embarrassing, but
it'd explain a lot).

> I've been over the thread-per-block scheduler code a lot in the past
> few years. What you are suggesting here is, frankly impossible. <snip>

Totally understand and agree. I'll admit it was a bit careless to
assume and speculate so much, but I'm simply flummoxed as to why
sequential data would work while random data does not. I've never
heard of any bug or feature (other than branch prediction) that would
care whether the data was random or not. The fact that the file size
contributes is confusing as well. I've done much testing on the
individual blocks and everything seems to check out.

> I suspect the change in behavior observed by the original poster is
> caused by a race condition that manifests itself differently depending
> on the relative speed of different flowgraph threads, to which branch
> prediction failure rate would contribute.

This was certainly my first thought of what could be happening,
especially due to the server communication that's used and the
threading model it uses. But after removing the server references from
the flowgraph, the issue still occurs. The encode, decode, and BER
block do not share any common variables and certainly no variables
that persist outside of the work function. Is it possible a race
condition is still occurring, even with nothing shared among blocks?