Edouard A. wrote:
In which case it would be nice to have some sort of "root" task on which other tasks depend. You would only need to wait for the root task to finish, making code simpler to write (and maybe the waiting more efficient to write?).
If you want a lightweight mechanism and can afford to be 'a bit wrong' then you could just assign task ids from a 128-bit number and return the id from submission, then you could perhaps wait for 'lowest task > n'. In most systems you get a more-or-less FIFO approach and it won't be far out - and its cheap. That or perhaps have a 'task group' facility where you can optionally associate tasks with a group and check the waiting+executing count per group, which might use an atomic counter and an event that fires iff the atomic decrement went to 0. I think you have to allow pools to have extremely bursty usage patterns and high throughput - anything that. locks, sorts or otherwise stalls the queue is Bad News. James