Proposal Threading and Acceleration

From Audacity Wiki
Revision as of 21:44, 13 October 2014 by Andrew Hallendorff (talk | contribs) (Created page with "{{Proposal_Header| This proposal page is about Threading and Acceleration. }} __TOC__ == Proposed Feature == Most if not all modern computers have multiple cores, GPUs, and ot...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Proposal pages help us get from feature requests into actual plans. This proposal page is about Threading and Acceleration.
Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.


  • Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.

Proposed Feature

Most if not all modern computers have multiple cores, GPUs, and other accelerators all capable of executing the instructions necessary to make a program work. To make use of all this processing power, programs must implement varying levels of gates and sandboxes. Depending on the algorithm, splitting up these pieces and controlling their flow can range from trivial to Rube Goldberg esque. Accomplishing this will require both support libraries and strict rules. This proposal is about laying out these operations.

Developer/QA/Guest Programmers backing

Andrew Hallendorff

Common Terms and Definitions

(note: These are just a few definitions to help understanding. Feel free to better my definitions)

Thread

The defined environment necessary for one program entry execution.

Thread Safe

A way of arranging the resources and controls such that multiple threads can exist in the same environment.

Semaphore

A gate that controls how many threads pass through.

Mutex

(aka: Mutual Exclusion) Maintains coherency between threads preventing parallel operations from executing on same resource.

Producer Consumer

The relationship where one part of a program sets up the execution of another. Often 1 to many or many to many.

Race Condition

When more than one part of a program depends on the time of execution.

Deadlock

When two or more consumers create a situation where they own the resource the others want. This usually stops execution.