Stock race condition
A shop keeps one shared stock count for a popular item, and several checkout requests run against it at once. A request takes two steps. Its "read" copies the current stock into that request's own local view. Its "commit" confirms the order when the local view is at least the quantity the request wants, subtracting that quantity from the shared stock; when the local view is smaller the request is cancelled and nothing changes. You are given the starting stock, a list where quantities[i] is what request i wants, and a schedule of events "i|step" such as "2|read" or "2|commit" that is one interleaving of the requests. Every request reads once before it commits once. Commit judges the local view, not the live stock, so the count can end below zero. Return a pair [final_stock, confirmed_orders].
simulate_oversell(stock: int, quantities: list[int], schedule: list[str]) → list[int][5,[4,4],["0|read","1|read","0|commit","1|commit"]]out[-3,2][5,[4,4],["0|read","0|commit","1|read","1|commit"]]out[1,1][10,[3,5,4],["0|read","0|commit","1|read","2|read","1|commit","2|commit"]]out[-2,3]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.
[5,[4,4],["0|read","1|read","0|commit","1|commit"]][-3,2]not run yetsample[5,[4,4],["0|read","0|commit","1|read","1|commit"]][1,1]not run yetsample[10,[3,5,4],["0|read","0|commit","1|read","2|read","1|commit","2|commit"]][-2,3]not run yetsample