Вот смотри, есть queue которые делятся на 2 контейнера, один последовательный, второй нет

Я говорил, что такк и так будет синхронизация, не вижу, где выигрыш

Затем у каждого класса такой задачи есть состояние типа uint64_t, который хранит в себе информацию с помощью битов о том, где в последний раз выполнялся

У нас задача может быть в 2 состояниях

1) Задача успешно выполнилась
2) Задача не выполнилась, остановилась на шаге N в связи с тем, что блок был недоступен так как был занят другим потоком

В первом случае задача если выполнилась - убирается из queue к примеру, во втором случае поток увидел что на каком то месте выполнения задачи код занят другим потоком, он выполнят прыжок в конец и идет брать другую задачу, а не ждет пока второй поток освободится, но при этом, прежде чем уйти - он сохраняет текущее состояние, например, если будем использовать uint64_t, то 1/4 часть битов выделяем под тип функции, где остановились, а остальные под определения шага выполнения

Представим, задача не выполнилась до конца в связи с тем, что какие то общие контейнеры были заняты, то мы идем делать другую работу, а потом какой нибудь поток возьмет эту задачу что мы не выполнили и пойдет вызывать ее методы последовательно, в каждой функции нужно создать некие подразделы которые можно отслеживать по битовому полю, мы проверяем, для текущего региона кода бит выставлен в 1 или 0, если 1, то значит нам не нужно этот участок кода уже выполнять - выполняем goto к второй части и так до тех пор, пока не дойдем до задачи где бит в 0, значит там мы и остановились - продолжить выполнение

А когда задача завершится - объект сам будет уничтожен и состояние задачи обнулится

Единственная сложность здесь вот в чем, где хранить временные данные, например, я хотел записать данные что обработал в контейнер, а он был занят другим потоком

Такие данные можно сериализовывать в простой плоский буффер

Не думаю что этот буффер будет большим

И к тому же, десериализация такого буффера не имеет высокой сложности, всего лишь последовательно вытаскиваем типы данных

Собственно, отсюда возникает вопрос, что дороже обойдется, ожидание потока пока другой поток освободит какой то общий контейнер или же сериализация/десериализация и проверка битовых полей?

Другая сложность в том, что нам самим придется как то создавать систему меток для каждой задачи и её функций, а далее функции подфункции

Но по сути, человек с хорошим опытом в С++ думаю выполнит эту задачу создав какой нибудь волшебный класс или макрос

Чтоб уменьшить геморрой расстановки таких меток - переходов

Корутины, что ли изобретаешь на goto?

Нет

Это другое

Идея примерна та же