Jump to a problem, path or page
Jump to a problem, path or page
Updates as you edit. Run the review to record it; passing every check completes the problem.
Not yet passed: Caller responsibility
Add Caller and define its responsibility.
Not yet passed: Timer scheduler responsibility
Add Timer scheduler and define its responsibility.
Not yet passed: Deadline heap responsibility
Add Deadline heap and define its responsibility.
Not yet passed: Clock responsibility
Add Clock and define its responsibility.
Not yet passed: Wake condition responsibility
Add Wake condition and define its responsibility.
Not yet passed: Callback runner responsibility
Add Callback runner and define its responsibility.
Not yet passed: Caller → Timer scheduler
A directed path must connect Caller to Timer scheduler. Arrows represent requests, dependencies, or event flow.
Not yet passed: Timer scheduler → Deadline heap
A directed path must connect Timer scheduler to Deadline heap. Arrows represent requests, dependencies, or event flow.
Not yet passed: Timer scheduler → Clock
A directed path must connect Timer scheduler to Clock. Arrows represent requests, dependencies, or event flow.
Not yet passed: Timer scheduler → Wake condition
A directed path must connect Timer scheduler to Wake condition. Arrows represent requests, dependencies, or event flow.
Not yet passed: Timer scheduler → Callback runner
A directed path must connect Timer scheduler to Callback runner. Arrows represent requests, dependencies, or event flow.
Not yet passed: What if a new earlier timer is inserted?
Not yet passed: How do stale heap entries from reschedule behave?
Not yet passed: Where should callback invocation occur?
Not yet passed: Interfaces and invariants
Write at least 80 characters describing concrete operations, inputs, outputs, state and errors. This check measures completeness, not semantic correctness.
Not yet passed: Trade-offs and failure cases
Write at least 80 characters about alternatives, failure handling and edge cases. Review the reasoning yourself using the reference discussion.
Rule-based educational feedback. Notes are checked by length only; topology checks confirm directed reachability. These checks do not validate semantics, latency, reliability or every valid design.
Use a min-heap of monotonic deadlines and generation-tagged timer records. A dispatcher condition loop claims due callbacks under lock and invokes them outside the lock with explicit cancellation semantics. Schedule creates an active timer and pushes (deadline, insertionSequence, id, generation). Equal deadlines follow insertion order; relative delays become monotonic deadlines once. Reschedule increments generation and pushes a new entry. Cancel transitions an unclaimed active record to canceled. Wake the dispatcher whenever the effective earliest deadline may change. The dispatcher skips stale entries, waits until the live earliest deadline and atomically claims a due callback. Cancel after claim returns TooLate. The callback runner invokes outside the lock and reports exceptions separately. Shutdown stops new admission, wakes waits and cancels pending timers under this policy. Claimed callbacks finish/cooperatively stop; obsolete heap entries are periodically compacted to bound memory.
There is no single correct diagram. Explain where yours differs and which requirement justifies it.