Система, управляемая событиями и SST(super-simple tasker), Выделено из "ООП. Классы и динамические объекты" Опции

[brag]

Недавно я начал пользоваться динамической памятью. Раньше пользовался только статикой, то есть placement new. Со статикой сложно работать с такими шаблонами, как фабрика обьектов, временные задачи итд.
Программирую в основном под cortex-m3/m4
Код реализации аллокатора вышел довольно простым и быстрым, критически секции есть, но очень короткие(там прочитать/записать пару байт).
При чем я не использую этих всяких монстров под названием RTOS, у меня свой простейший асинхронный планировщик задач, занимает строк 300 кода с комментариями(погуглите запрос "super simple tasker", поймете что это).
В купе с динамическим аллокатором, variable element-size queue, новыми фишками C++ (шаблоны, лямбда-функции, auto) получается очень простой, безопасный и мощный фреймворк.
Вспоминаю работу с классическими Thread-ами(с ихними стеками - куча кода было написано для анализа программ на предмет нужного обьема стека, и теперь эта куча кода отправлена на мусорку) со всеми этими тяжеленными мютексами, семафорами, вечными циклами как страшный сон.

Если кому интересно - расскажу и покажу как это все работает.

[brag]

Хотя интересно было узнать то, что помимо стандартных new/delete, существуют и свои средства (стратегии) для управления кучами.

dew/delete никуда не деваются, но мы их можем перегружать и иметь свою реализацию. Потом есть всякие smart-pointerы и reference count-ы - это для того, чтобы голова за delete не болела. Но их надо использовать с осторожностью(равно как и delete)
Динамическая память напрямую связана с той средой, в которой работаете. В многопоточной среде динамическая память приводит к большим тормозам и проблемам - поскольку на время работы аллокатора надо блочить все потоки и планировщик, а возможно и часть прерываний. В то время как в SST-модели в этом нет необходимости, блочится только часть системы, а не практически вся.

Может быть выложите реализацию делегатов?
Сам использую свой велосипед и собираю велосипеды других с целью повышения образования.

Выложу ниже. Велосипеды/не велосипеды, но эта реализация отлично работает многие годы. А сделал я ее потому что когда я попытался применить нормальный std::function на Atmega8, то это сразу сожрало всю оператирку(и все рано ее не хватило), потянуло за собой кучу ненужного мусора. В итоге сделал этот велосипед na 80 строк(вместо нескольких тысяч в std) за час.

Держите статическую версию, в большинстве случаев ее достаточно. А на слабых МК (до 8-16кб оперативки) только она и уместна

CODE

template<class T, int d_size=1> class delegate;

template<class TRet, class... TArgs, int d_size>
class delegate<TRet(TArgs...),d_size> {
public:
delegate(){}

// copy constructor and copy operator=
template<int size_another>
delegate(const delegate<TRet(TArgs...),size_another>& another){
operator=(another);
}

template<int size_another>
delegate& operator=(const delegate<TRet(TArgs...),size_another>& another){
static_assert(sizeof(another) <= sizeof(*this), "RHS too large");
wrapper_ = another._private_get_wrapper();
for(unsigned i=0; i<sizeof(another._private_get_data()) / sizeof(data_.vp[0]); i++){
data_.vp[i] = another._private_get_data().vp[i];
}
return *this;
}

// lambda, static function and function object
template<class TLambda>
delegate(const TLambda& lambda){
setFunction(lambda);
}

template<class TLambda>
delegate& operator=(const TLambda& lambda){
return setFunction(lambda);
}

// For lambda, static function and function object
template<class TLambda>
delegate& setFunction(const TLambda& lambda){
struct Wrapper{
Wrapper(const TLambda& lambda) : la(lambda) {}

static TRet wrapper(void* data, TArgs ... args){
Wrapper *w = static_cast<Wrapper*>(data);
return w->la(args...);
}

void* operator new(size_t, void *place){ return place; }

TLambda la;
};
static_assert(sizeof(Wrapper) <= sizeof(data_), "Wrapper too large");

new(&data_) Wrapper(lambda);
wrapper_ = &Wrapper::wrapper;
return *this;
}

// invoke wrapper
TRet operator()(TArgs ... args){
return wrapper_(&data_, args...);
}

TRet operator()(TArgs ... args)const{
return wrapper_(const_cast<t_data*>(&data_), args...);
}

private:
typedef TRet (*t_wrapper)(void*, TArgs...);

t_wrapper wrapper_;
union t_data{
void *vp[d_size];
} data_;

// really private
public:
const t_wrapper& _private_get_wrapper()const{ return wrapper_; }
const t_data& _private_get_data()const{ return data_; }
};

Несмотря на такое изобилие кода(который делается 1 раз) на самом деле для выполнения делегата компилятор генерирует 2 инструкции(на кортексе) - чтение указателя wrapper и прыжок на него
А тело самой функции-делегата встраивает в wrapper, фактического вызова функции внутри wrappera нет.
Создание делегата тоже очень простая операция - запись указателя(одна инструкция) и запись данных(обычно тоже одна инструкция, в зависимости от обьема данных - сколько слов, столько и инструкций или одна STM для всех)

[Serhiy_UA]

dew/delete никуда не деваются, но мы их можем перегружать и иметь свою реализацию. Потом есть всякие smart-pointerы и reference count-ы - это для того, чтобы голова за delete не болела. Но их надо использовать с осторожностью(равно как и delete)

В моем случае под 7 версией FreeBCD на индустриальном компьютере в режиме реального времени одновременно работают пять равно приоритетных программ. Каждая через new/delete (без перегрузок) создает для себя динамические объекты в куче. Если куча общая, то ОС должна четко организовывать управление кучей для всех программ. Хотел узнать (прочесть) об этом немного больше, хотя и так кое-что уже прояснилось.

[brag]

Очень бы хотелось увидеть как бы вы обслуживали много клиентов, рисовали GUI и делали еще то что нужно и именно на голой системе и именно со своим SST и чтоб в масштабах ВСЕЙ системы был бы один стек и один поток. Собственно это то, с чего мы начинали нашу дискуссию.

Так я именно это и постоянно делаю! У меня GUI, сложные вычисления, куча IO(флешки,ацп,датчики 1wire) отлично работают на SST без единых тормозов и проблем. На многопоточной оси аля FreeRTOS постоянно были проблемы, то гонки, то оверхед большой, то еще что-то.

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

Ну так они реализованы - это SST При чем довольно просто, сам SST - это около 300 строк кода, динамическая очередь - почти 200 строк кода, очередь задач - 60 строк кода, делегат(Вы уже его видели выше) - 80 строк кода

Правильно уже вам тут говорили, вы даже реализацию TCP/IP со своим SST запаритесь делать.

Сделана и отлично работает.

Начали мы с SST где один стек и один поток на всех в системе давайте и будем продолжать в том-же духе.

Ну так я показал, как на своем SST я работаю с DataFlash - привел полный код операции ее стирания. Что там непонятного? Могу любую другую задачу показать как я делаю ее на SST. Говорите какую - приведу код, тк у меня практически все задачи уже решены в виде простейших библиотек и я их использую когда надо - строю программу из этих кубиков.

В моем случае под 7 версией FreeBCD на индустриальном компьютере в режиме реального времени одновременно работают пять равно приоритетных программ. Каждая через new/delete (без перегрузок) создает для себя динамические объекты в куче. Если куча общая, то ОС должна четко организовывать управление кучей для всех программ. Хотел узнать (прочесть) об этом немного больше, хотя и так кое-что уже прояснилось.

Ну в таких сложных ОС, как FreeBSD управление кучей очень сложное. Куча для каждого процесса своя, а для потоков внутри этого процесса общая, и ессно ядру нужно ею управлять так, чтобы это не сказывалось на других процессах, там все довольно сложно и вникать туда смысла нет - жизни не хватит.
Зато есть смысл делать динамику на embedded, где и памяти мало, и других ресурсов, но чувствовать себя там практически так, как будто под PC пишешь.

В FreeBSD там все довольно грамотно да и работать в асинхронном стиле(без ожиданий и циклов) там гораздо проще, чем в линуксе. В линуксе до сих пор нет нормальных асинхронных IO, есть костыли вроде epoll. Тогда как в FreeBSD есть Kqueue. Думаю, если мой тест запустить на FreeBSD, то NodeJS еще сильнее убьет в хлам классические pthread.

А тем временем провел другой тест - сервер выдает не файл(который ОС выдает из кеша, а не читает по факту с диска) а рандомные данные по таймеру по 100 байт каждые 10 милисекунд вечно, пока клиент не отключится.
Вот так это выглядит на NodeJS, в однопоточном асинхронном стиле:

Код

        var timer;
        function on_socket_closed(){
            n_connections--;
            clearInterval(timer);
        }

        // Periodically send random data to client
        timer = setInterval(function(){
            var str;
            for(var i=0; i<100; i++){
                str+= String.fromCharCode(Math.random()*256);
            }
            socket.write(str);
        }, 10);

То есть для каждого клиента мы создаем таймер, в обработчике события которого генерируется рандом и потом ставится в очередь на отправку клиенту. Не шибко эффективный способ,тк время генерации рандома велико - тк это мы делаем синхронным блокирующим способом - в цикле for. правильно было бы прoчитать эти данные из готового асинхронного рандом-генератора (типа /dev/urandom) и передать клиенту - моментально, одной строчкой. Но тк я буду делать то же самое на С, только в многопоточном стиле - специально сделал так, чтобы сразу не убить в хлам многопоточную модель
И того такой сервер на моем ноуте может обслуживать 3900 клиентов одновременно и занимает при этом 80МБ оперативки. При чем клиент запущен на том же ноуте, асинхронный тот же, что и прежний, на JS.

Сейчас наклепаю на C в мнгопоточном блокирующем стиле.