Add fiber queues for execution context schedulers

[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.

[ysbaddaden]

The MinGW failure on CI should be fixed by #15404.

[straight-shoota]

Hm, that'll leave MinGW broken until we merge that fixup then? 🤔

[ysbaddaden]

That's possible, yes.

We might want to split #15404:

• add Fiber.new(name, stack, stack_bottom, &proc) in a new PR: Initialize Fiber with an explicit stack #15409
• add #new_fake_fiber to this PR, and use it in the queue specs;
• fixup RFC 2: Skeleton for ExecutionContext  #15350 to add the execution_context parameters.

[ysbaddaden]

Updated to add:

1. cherry-pick the commit that adds the stack arguments to Fiber#initialize;
2. use fake stacks in the queue specs.

Let's avoid any further changes 🤞

[ysbaddaden]

Following the addition of Fiber::Stack in #15409, the new_fake_fiber helper will need to be updated.

[ysbaddaden]

I replaced the last couple commits to integrate #15434 and the last version of #15409 and a fixup for new_fake_fiber to use Fiber::Stack.