discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Question about Cycle Detection in GNU Radio


From: Josh Blum
Subject: Re: [Discuss-gnuradio] Question about Cycle Detection in GNU Radio
Date: Wed, 10 Jul 2013 06:35:45 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7


On 07/09/2013 09:20 PM, Tommy Tracy II wrote:
> Another alternative would be to pass around shared pointers to a queue. Does 
> that seem like a reasonable, albeit hack-ee, approach?

Of course that could work, but then you arent really letting the
framework work for you. The scheduler handles all the thread spawning,
thread safety, delivery of information through the topology...

At its core, the scheduler is just a collection of threads and shared
queues. So you dont have to re-implement that :-)

-josh

> 
> Sincerely,
> Tommy James Tracy II
> Ph.D Student
> High Performance Low Power Lab
> University of Virginia
> Phone: 913-775-2241
> 
> On Jul 9, 2013, at 5:46 PM, Josh Blum <address@hidden> wrote:
> 
>>
>>
>> On 07/09/2013 08:25 PM, Johnathan Corgan wrote:
>>> On 07/09/2013 05:06 PM, Tommy Tracy II wrote:
>>>
>>>> I am working on a GNU Radio Router block that will serve as a 
>>>> communication block between multiple flow graphs. My router will
>>>> receive information via TCP, and then send it to several other
>>>> blocks to be processed. After those blocks have completed their
>>>> processing, my original idea was to take that data and return it
>>>> to the router to be sent back to a different node. This would
>>>> introduce a cycle in the flow graph. Is there any way to disable
>>>> cycle prevention?
>>>
>>> There is no way to disable cycle prevention; the GNU Radio
>>> scheduler algorithm requires streaming ports to be a directed
>>> acyclic graph.
>>>
>>> However, this applies to streaming ports only.  It's possible
>>> (though probably lower in performance) for you to encapsulate data
>>> into async messages and use message ports connected in an arbitrary
>>> topology.
>>>
>>>
>>
>> Checkout the advanced scheduler. There is no problem with feedback
>> loops, and there is no penalty for passing buffers as messages instead
>> of streams: https://github.com/guruofquality/gras/wiki
>>
>> -josh
>>
>>>
>>> _______________________________________________ Discuss-gnuradio
>>> mailing list address@hidden 
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 



reply via email to

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