Description

Last week I spent most time writing the experiment and figure out what metrics matters. I have tried to dedicate myself to write at least a section each week to keep up with the schedule, but sadly I barely managed to write down 3 sentences. I do hope that it will eventually flow better.

I recognized that I have not written what the project is about. I first thought that the brief explanation in PixelMap would describe this, and as it will definitely change over time, it could be confusing over time. However, I could give a general description closely related to what I wrote two weeks ago. It also helps me find different ways to describe what I am actually doing.

For a multi-threaded program there exist some sort of scheduler to distribute tasks over different cores. The scheduler could be a thread-safe queue, but scheduler that have been more researched for the last 40 years is the multi-queue. The implementation of this type of queue is that it will contain at least as many queues as available threads. This reduces wait times significantly, because you could randomly iterate through each queue and try each lock until you find one that is free. To improve this further, one could retrieve a bunch of tasks at the same time and process those before asking for more tasks. The paper is currently related to this improvement, multi-queue task batching.