You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GNU Radio in its 3.11 release cycle faces many challenges, architectural baggage chief among them. This SDG proposal aims to fund development work on core components that can't be done on a volunteer basis
GNU Radio is currently in its 3.10 stable release cycle, delivering stability and reliabilty to its current users. However, architectural constraints have been identified that inhibit GNU Radio being used in more message-processing oriented frameworks.
This foremostly affects GNU Radio's core locking against multithreaded access race condition. In its current implementation, the core has a very simple one-mutex-locks-all-properties locking mechanism to protect each block, each of which runs in its own thread. This single mutex per block makes access both in read and write exclusive to a single thread, and has no granularity at all, but blocks access to ring buffers, message passing data structures, sample annotation data structures, resampling block properties, and more. This is a severely limiting factor in performance.
But worse: It makes it impossible to call into python code from the context of the block executor, because this would require holding both the Python GIL and the block mutex, something that is architecturally impossible at the same time in most contexts.
Thus, this prohibits GNU Radio's integration in Python data processing flows. There's multiple scientific and commercial consumers of GNU Radio's API that would benefit from that.
Fixing these will take significant time, coordination and quality assurance.
At the same time, with the retirement of its last volunteer maintainer, the project scrambles to find capable developers that are experienced enough in its runtime core to tackle these architectural issues, as the same people are now sharing the workload of day-to-day project maintenance.
This small development grant would go into allowing a core dev to reassign their freelance time to working on GNU Radio's core without compromising on rent and food.
Amount requested
8800
Execution plan
Who will implement this?
The core developer that would be willing to work on this is @marcusmueller (disclaimer: who's also been tasked with writing this grant proposal).
What's the Timeline?
The timeline is here is, to be worked on in parallel:
Locking Overhaul (75h)
June 15: start of coding, publication of prioritized list of deliverables
July 16: presentation of preliminary results and coordination with other core developers at the European GNU Radio hackaton in Lyon, France
July to September: Realization of a multi-reader, single-writer fairness based locking scheme for the GNU Radio block
September 8-12: Participation in the GNU Radio conference 2025 (Everett, Washington, USA) to present results, receive feedback
Bugfix burndown (12h)
June 15 to September 15: unblocking upstream contribution to the above issues by removing blocker bugs as already known on the GNU Radio issue tracker
How will it be done?
Marcus Müller is a central member of the GNU Radio developer community and will hence work in close coordination with the supervising GNU Radio leadership (GNU Radio General Assembly & Board) as well as with the general community.
He'll stick to coding standards as established within the project.
Budget Aspects
Hourly rates and number of work hours for contractors
The allotted hours (75h + 12h = 87h) and the requested amount ($ 8800 total - $ 100 travel = $ 8700) come down to an hourly rate of 100 $ /h, but are for planning purposes and need to be understood as minimum of work hours to be done to deliver the outlined goals. Should, contrary to planning, less time be needed to implement the desired goals, "overhang" hours are invested into additional maintenance work.
Equipment and/or supply costs if applicable
Not applicable
Cost of any services
No additional services required
Travel costs
An amount of $ 100 is reserved to sponsor travel to the European GNU Radio hackfest.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Project
GNU Radio
Summary
GNU Radio in its 3.11 release cycle faces many challenges, architectural baggage chief among them. This SDG proposal aims to fund development work on core components that can't be done on a volunteer basis
submitter
Marcus Müller @marcusmueller
project lead
@mormj
Community benefit
GNU Radio is currently in its 3.10 stable release cycle, delivering stability and reliabilty to its current users. However, architectural constraints have been identified that inhibit GNU Radio being used in more message-processing oriented frameworks.
This foremostly affects GNU Radio's core locking against multithreaded access race condition. In its current implementation, the core has a very simple one-mutex-locks-all-properties locking mechanism to protect each block, each of which runs in its own thread. This single mutex per block makes access both in read and write exclusive to a single thread, and has no granularity at all, but blocks access to ring buffers, message passing data structures, sample annotation data structures, resampling block properties, and more. This is a severely limiting factor in performance.
But worse: It makes it impossible to call into python code from the context of the block executor, because this would require holding both the Python GIL and the block mutex, something that is architecturally impossible at the same time in most contexts.
Thus, this prohibits GNU Radio's integration in Python data processing flows. There's multiple scientific and commercial consumers of GNU Radio's API that would benefit from that.
Fixing these will take significant time, coordination and quality assurance.
At the same time, with the retirement of its last volunteer maintainer, the project scrambles to find capable developers that are experienced enough in its runtime core to tackle these architectural issues, as the same people are now sharing the workload of day-to-day project maintenance.
This small development grant would go into allowing a core dev to reassign their freelance time to working on GNU Radio's core without compromising on rent and food.
Amount requested
8800
Execution plan
Who will implement this?
The core developer that would be willing to work on this is @marcusmueller (disclaimer: who's also been tasked with writing this grant proposal).
What's the Timeline?
The timeline is here is, to be worked on in parallel:
Locking Overhaul (75h)
Bugfix burndown (12h)
How will it be done?
Marcus Müller is a central member of the GNU Radio developer community and will hence work in close coordination with the supervising GNU Radio leadership (GNU Radio General Assembly & Board) as well as with the general community.
He'll stick to coding standards as established within the project.
Budget Aspects
Hourly rates and number of work hours for contractors
The allotted hours (75h + 12h = 87h) and the requested amount ($ 8800 total - $ 100 travel = $ 8700) come down to an hourly rate of 100 $ /h, but are for planning purposes and need to be understood as minimum of work hours to be done to deliver the outlined goals. Should, contrary to planning, less time be needed to implement the desired goals, "overhang" hours are invested into additional maintenance work.
Equipment and/or supply costs if applicable
Not applicable
Cost of any services
No additional services required
Travel costs
An amount of $ 100 is reserved to sponsor travel to the European GNU Radio hackfest.
The text was updated successfully, but these errors were encountered: