Hi all,
I found the alternative queues defined at JCTools for various producer-consumer scenarios, seem awesome, except that I have an implementation problem.
My problem is that I need to start that consumer loop. And preferably to stop it whenever there are no more elements. But unfortunately this means the producers end up contending with the consumer on some sort of AtomicInteger keeping track of the queue’s current size, by doing something like this:
// on the producer side
if (eventsToProcess.getAndIncrement() == 0)
threadPool.submit(startConsumerRunLoop())
// ... later, in the consumer loop ...
next = queue.poll()
if (next == null) {
eventsToProcess.decrement(processedCount)
continue = false
}
else {
processedCount += 1
// ...
}
Otherwise I can see no way around this, except for keeping a single loop active and continuously polling once every X milliseconds. But then polling seems to be wasteful, when having many such producer-consumer pipe lines in the same process, as that means having multiple loops actively polling on producers that might not be that active. And if I would set the polling to a very relaxed period, like say, once every 200 milliseconds, then that’s serious latency when events do happen added for no reason. And I’d introduce a mixture based on wait
and notify
but I can’t see how I can build something cheaper than doing synchronization by means of an AtomicInteger
as described above.
So my actual question: besides keeping track of the queue size with an AtomicInteger
and starting a run-loop when that’s zero and besides dumb polling when the queue is empty, do I have any other choices?
I’m asking this, because on one hand I’m excited about using something better than j.u.c.ConcurrentLinkedQueue
, but on the other hand the advantages of a lock-less or even wait-free queue implementation seem in principle to not be a great win if I have to contend on an AtomicInteger
just for starting that consumption loop.
—
Alexandru Nedelcu
alexn.org
--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
AtomicInteger
in all lock free queues per say. That is specific to your implementation and not not necessarily true (luckily) for all lock free queues out there ! How you wait is left as an added benefit/exercise to you !