Hacker News new | past | comments | ask | show | jobs | submit login

I wonder if there’s a way to integrate futexes in there to let consumers and producers park. Otherwise whenever the rate of production or consumption is meaningfully different (which it is in the real world), there’s a lot of CPU being wasted…



A lock free queue still helps to have, even if you use an explicit semaphore or futex to synchronize threads at a higher level. A producer can queue up multiple items per post, and a consumer can empty the queue between pends. Without the lock free queue, the queue itself would have to be protected by a mutex. It's actually nice when lock free data structure implementations leave OS level synchronization up to the caller. It makes the implementation more generally useful and portable. It's perhaps a less obvious example of "dependency injection".


I can't speak to the use case of TFA, but in some contexts where similar data structures are prominently used we park by spin waiting (which may include looking at all our other queues) because we don't want to pay a bunch of microseconds of latency for actually being descheduled and resheduled again.

Maybe TFA is for embedded use?


I don't see how spin waiting constitutes parking? In what sense is the execution context "parked" if in fact it's just spinning?


Not the GP, but I read "we use spin waiting" as a response to "aren't you wasting a bunch of CPU cycles" in the sense that "yes, but it's the least bad option".


Yes! You can use (futex based) event counts to add blocking behaviour to any lock free queue.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: