pipeline: make pipeline_barrier context-aware, give each stage its own barrier - #101
Closed
aryanputta wants to merge 1 commit into
Closed
aryanputta wants to merge 1 commit into
aryanputta wants to merge 1 commit into
Conversation
…n barrier Closes one of the blockers identified in IBM#100. Root cause: pipeline_barrier ignored its context parameter and always wrote events to the module-level _main_barrier_context singleton. All four barrier registrations in register_processing_functions shared one queue, making it impossible to scope a barrier to a specific logical stage group and making the context parameter misleading. What changed: barrier.py - Rename _BarrierContext to BarrierContext (public) so call sites can create independent instances without importing a private name. - pipeline_barrier now uses the context it is passed (ctx.collect(event)) instead of the global singleton. _main_barrier_context is kept as a convenience singleton for any call site that wants shared-barrier semantics, but it is no longer hardwired into the function. pipeline/__init__.py - Export BarrierContext alongside _main_barrier_context so acelyzer.py and future PipelineStage code can create instances via the normal event_pipe namespace. acelyzer.py - Each of the four logical barrier groups in register_processing_functions now owns a named BarrierContext instance: normalize_barrier_ctx -- frequency_align stage overlap_barrier_ctx -- overlap_tid detection (conditional) comm_barrier_ctx -- comm_summarize / rcu_util stage categorize_barrier_ctx -- event categorizer stage - No change to registration order or conditional logic; the only difference is which context each barrier call receives. tests/aiu_trace_analyzer/pipeline/test_barrier.py - Update existing test to pass a BarrierContext instance explicitly (previously passed None, which only worked because the function ignored its argument). - Add test_independent_barrier_contexts_do_not_share_events: two barriers with separate contexts hold and drain their events independently. - Add test_barrier_drain_clears_hold: drain returns events and leaves the context empty. Signed-off-by: Aryan Putta <aryansputta@gmail.com>
aryanputta
requested review from
WarningRan,
eklee15,
lasch,
mcalman and
yuhaohaoyu
as code owners
April 24, 2026 03:33
Contributor
Author
Contributor
Author
|
Superseded by #102 which combines both steps into one PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
First concrete step toward the pipeline restructuring tracked in #100.
pipeline_barrierignored its context parameter and always wrote events to the module-level_main_barrier_contextsingleton. All four barrier registrations inregister_processing_functionsshared one queue. That made independent per-stage barriers impossible and made the context parameter misleading — every call site passedevent_pipe._main_barrier_contextbut the function never used it.Root cause
Changes
src/aiu_trace_analyzer/pipeline/barrier.py_BarrierContextrenamed toBarrierContext(public) so call sites can create instances without importing a private name.pipeline_barriernow usesctx.collect(event)— the context it is passed — instead of the hardwired global._main_barrier_contextis kept as aBarrierContext()singleton for backwards compatibility; any call site that still passes it gets the same shared-barrier semantics as before.src/aiu_trace_analyzer/pipeline/__init__.pyBarrierContextexported soacelyzer.pyand futurePipelineStagecode can create instances via the normalevent_pipenamespace.src/aiu_trace_analyzer/core/acelyzer.pyregister_processing_functionsnow owns a namedBarrierContextinstance:normalize_barrier_ctxoverlap_barrier_ctxcomm_barrier_ctxcategorize_barrier_ctxNo change to registration order or conditional logic.
tests/aiu_trace_analyzer/pipeline/test_barrier.pyBarrierContextinstance (previously passedNone, which only worked because the function ignored its argument).test_independent_barrier_contexts_do_not_share_events: two barriers with separate contexts hold and drain their own events independently.test_barrier_drain_clears_hold: drain empties the hold list.Validation
What this unblocks
With barriers context-aware and
BarrierContextpublic, aPipelineStageclass (next step in #100) can own its barrier instance and callpipeline_barriercorrectly without any global state. The_main_barrier_contextsingleton is still available for the shared-barrier case but is no longer required.