service SharedMiningService { rpc GetWords ( GetWordsRequest ) returns ( GetWordsResponce ) {} } message GetWordsRequest { repeated int64 word_indexes = 1; } message GetWordsResponce { repeated bytes words = 1; }

ok, I need a super fast sorting queue

basically, need to shard my queue so that it isn't blocking all the threads all the time

"LayerWorkThread(snowblossom.miner.FieldSourceRemote@1622f1b)" #840 daemon prio=5 os_prio=0 tid=0x00007f03a0c24000 nid=0x9ca waiting for monitor entry [0x00007ef55c809000] java.lang.Thread.State: BLOCKED (on object monitor) at snowblossom.miner.Arktika.enqueue(Arktika.java:541) - waiting to lock <0x00007ef6e0195aa0> (a com.google.common.collect.MinMaxPriorityQueue) at snowblossom.miner.BatchLayerWorkThread.processPw(BatchLayerWorkThread.java:122) at snowblossom.miner.BatchLayerWorkThread.runPass(BatchLayerWorkThread.java:96) at snowblossom.miner.LayerWorkThread.run(LayerWorkThread.java:190)

why do you care if it's sorted?

guess I could go look at the code...

it is good to be sorted a little

so we can do the the work that is closer to done first

and if the queue gets full, discard the ones that are less done

but it doesn't need to be sorted so much as bucketed

since there are only 6 states

a batch load of items that are all one pass level would be good too

that happens a lot

yeah, I would use 6 distinct queues

or stacks

I would use stacks

Sure. Also need to shard further. The problem is a bunch of threads dumping a bunch of entries

adding an item to a stack is ridiculously fast. I doubt there will be contention issues.

I think you underestimate my stupidity

https://dzone.com/articles/a-specialized-high-performance-concurrent-queue This look at Java performance proposes an alternative to java.util.concurrent.BlockingQueue for multiple writing threads and a single reading thread in a queue.

there you go

ConcurrentLinkedQueue<E>

On of those for each bucket should get it done