UserAB1236872
commented
8 years ago The main issue I see is that the particulars of scheduling ticket passing could have a huge impact on performance, especially if there are separate Read and Write tickets, because waiting on a Write ticket could, theoretically, block indefinitely.
A potential solution is resolving tickets in a sort of "generational priority-queue" manner, where every time a set of tickets is doled out, pending tickets increase their priority, to prevent any system from waiting too long.
If a read ticket is encountered before a write ticket, all read tickets for that component in the queue are passed out, and the pending write tickets have their priority increased. If a write ticket is encountered first, it gets exclusive access to the component and the read tickets get their priority increased. The difficulty here being that to handle this tickets can't be for a single component, and would need to be constraint-based to prevent system deadlock where two systems need each other to release a component they've reserved.
This could potentially be fixed with some sort of provisional system where if all tickets can't be supplied to a system, the entries are re-inserted with the same or a lower priority.
Systems could also supply a base priority for their system (so, e.g., rendering, audio, or input handling systems that require low latency can pass a priority of 10000000 which means "always run as soon as requested.")
@Amaranth on IRC suggested an interesting method of locking that has a potential to improve our parallilization abilities greatly. Basically, each system gets tickets for the components it needs first, not actually locking them, and then waits for the tickets to come, in parallel.
Candidate: https://github.com/amaranth/queuedrwlock