Code Room
CodingHardcod-g1133
Subject LockLevel Mid–Senior~30 minCommon in Concurrency interviewsIndustries Software development, Technology

Question

Simulate a read-write lock with a writer-priority, non-reentrant policy. requests is a list of [id, mode] where mode is 'R' (shared read) or 'W' (exclusive write), each requesting the lock in order and never releasing until granted-then-immediately-released in grant order. Use this deterministic rule to produce the GRANT order: process requests greedily from a waiting list; multiple consecutive readers can be granted together (and released together) as one batch, but a writer must hold the lock alone. To enforce writer priority, whenever the next waiting request in input order is a writer, it must be granted before any later reader. Concretely: scan the waiting list in order; if the head is a writer, grant just that writer; if the head is a reader, grant the maximal prefix of consecutive readers from the head. Return the list of ids in the order they are granted.

Implement
rwlock_grant_order(requests: list[list]) → list[int]
Examples
in[[[1,"R"],[2,"R"],[3,"W"],[4,"R"]]]out[1,2,3,4]
What a strong answer looks like

State your approach and its time/space complexity out loud before you optimize. Handle the edge cases (empty input, duplicates, overflow), and say why you chose this over the brute force. Green tests are the floor, not the grade.

Vibe coding: describe the solution in plain language (or narrate it) and the coach grades your approach. Generating runnable code from your description is coming next.

Run or narrate your approach, then ask the coach.