RFC 2: Queues

[ysbaddaden]

Introduces 3 queues that will be used the ExecutionContext schedulers. They derivate from Go's internal queues (q, runq and globrunq).

1. Fiber::Queue: holds an unbounded singly-linked list of Fiber with a bulk insert operation.

   Note: we may consider renaming Fiber::Queue as Fiber::List and Fiber#schedlink as Fiber#list_next?

2. ExecutionContext::GlobalQueue: wraps a Fiber::Queue with optional thread-safety and a bulk grab operation. There will be a single global queue per execution context shared among one or more schedulers.

   The point is to have an unbounded space to store as many fibers as needed, or to store cross context enqueues —the runnables queue below only supports a single producer.

3. ExecutionContext::Runnables: a bounded, lock-free, chase-lev queue (single producer, multiple consumers) with bulk operations. There will be a one runnables queue per execution context scheduler (aka local queue).

   On overflow or underflow it pushes/grabs half the queue size to/from the global queue (locking the mutex once in a while).

   Any scheduler can steal from any runnables queue in the execution context at any time, directly into their own local queue.

   The point is to have a quick list to push/pop and steal from, and to limit the occurrences where we must lock the scheduler mutex to reach to the global queue.

Refs #15342

[BlobCodes]

Fiber::Queue: holds an unbounded singly-linked list of Fiber

Isn't that a Stack / LIFO?

[yxhuvud]

How much of the queues will be public interface that are hard to change later on?

[ysbaddaden]

@BlobCodes Yes, it's a LIFO singly linked list (in contrast to the FIFO doubly linked list of Crystal::PointerLinkedList).

@yxhuvud Good call, they should all be :nodoc: (I missed GlobalQueue) at least for the time being!

[ysbaddaden]

Moved to Fiber::ExecutionContext as per #15350.