Орг. вопросы по версии 5.0 и по гитхабу.
299 views
Skip to first unread message
Anton Gusev
Nov 9, 2015, 6:43:17 AM11/9/15
to scmrt...@googlegroups.com
Всем привет!
(Создал новую тему, а то предыдущая у нас разрослась до неприличия).
Давайте сюда напишем, у кого есть какие планы на версию 5.0.
Ну и по гитхабу.
В списке участников проекта на данный момент видны только мы с Гарри.
Андрей и Сергей, вы у нас пока партизаны:)
Чтобы выйти из тени, надо зайти по адресу
https://github.com/orgs/scmrtos/people
и переключить "Private" на "Public".
(Создал новую тему, а то предыдущая у нас разрослась до неприличия).
Давайте сюда напишем, у кого есть какие планы на версию 5.0.
Ну и по гитхабу.
В списке участников проекта на данный момент видны только мы с Гарри.
Андрей и Сергей, вы у нас пока партизаны:)
Чтобы выйти из тени, надо зайти по адресу
https://github.com/orgs/scmrtos/people
и переключить "Private" на "Public".
Чуйкин Андрей
Nov 9, 2015, 7:43:37 AM11/9/15
to scmrtos-ru
Привет.
1. Добавить рекурсивный мьютекс + сопутствующие изменения.
2. Предложу слегка поправить интерфейс функций, используемых для контроля стека задач.
понедельник, 9 ноября 2015 г., 17:43:17 UTC+6 пользователь Anton Gusev написал:
понедельник, 9 ноября 2015 г., 17:43:17 UTC+6 пользователь Anton Gusev написал:
Harry Zhurov
Nov 10, 2015, 3:51:56 AM11/10/15
to scmrt...@googlegroups.com
09.11.2015 18:43, Чуйкин Андрей пишет:
--
HZ
> Предложу слегка поправить интерфейс функций, используемых для
> контроля стека задач.
Что конкретно предлагаешь?
> контроля стека задач.
--
HZ
Чуйкин Андрей
Nov 10, 2015, 4:42:36 AM11/10/15
to scmrtos-ru
Привет.
вторник, 10 ноября 2015 г., 14:51:56 UTC+6 пользователь Harry Zhurov написал:
В последнее время во всех своих проектах я контролирую расход стека задачами.
Для этого scmRTOS предлагает интерфейс в виде единственно функции stack_slack().
Одного единственного значения, возвращаемого этой функцией мне не достаточно, чтобы сделать вывод о расходе стека. 50 байт запаса по стеку - это много или мало? Наверное много, если размер стека 100 байт, и очень мало, если размер стека 8К. Т.е. для правильной оценки расхода стека, нужны два числа.
1. Собственно размер стека, выделенный под задачу.
2. Максимально использованное количества стека.
Эти значения легко получить и с использованием stack_slack(). Размер стека мы знаем, он задается при определении типа процесса. Использованное количество стека легко вычислить, зная его размер и запас. Но все это жутко неудобно. Чтобы пробежаться по всем задачам в цикле и вывести эту пару значений, нужно продублировать размеры стеков задач в массиве или еще как-нибудь изголяться.
Предлагаю вместо stack_slack() ввести две функции:
uint32_t stack_size();
uint32_t stack_max_used();
Благодаря этому, станет очень удобно выводить данные по стекам задач в виде пары значений выделено/использовано.
вторник, 10 ноября 2015 г., 14:51:56 UTC+6 пользователь Harry Zhurov написал:
Harry Zhurov
Nov 10, 2015, 8:18:21 AM11/10/15
to scmrt...@googlegroups.com
10.11.2015 15:42, Чуйкин Андрей пишет:
> Предлагаю вместо stack_slack() ввести две функции: uint32_t
> stack_size(); uint32_t stack_max_used();
>
> Благодаря этому, станет очень удобно выводить данные по стекам задач
> в виде пары значений выделено/использовано.
Резон понятен и обоснован. Но почему вместо? Почему просто не добавить?
Если убирать, то поломаем совместимость, раз. И второе - эта функция
(stack_slack) всё равно нужна (её функционал), это просто низкоуровневая
функция, которая даёт размер запаса. Нормировать или нет к размеру
стека, это уже следующий уровень функциональности/удобства. Если эта
пара функций, которую предлагаешь, ничему не мешает, ничего не ломает,
то добавить её, и дело с концом.
--
HZ
> Предлагаю вместо stack_slack() ввести две функции: uint32_t
> stack_size(); uint32_t stack_max_used();
>
> Благодаря этому, станет очень удобно выводить данные по стекам задач
> в виде пары значений выделено/использовано.
Если убирать, то поломаем совместимость, раз. И второе - эта функция
(stack_slack) всё равно нужна (её функционал), это просто низкоуровневая
функция, которая даёт размер запаса. Нормировать или нет к размеру
стека, это уже следующий уровень функциональности/удобства. Если эта
пара функций, которую предлагаешь, ничему не мешает, ничего не ломает,
то добавить её, и дело с концом.
--
HZ
Чуйкин Андрей
Nov 10, 2015, 10:42:49 PM11/10/15
to scmrtos-ru
Можно (нужно) и просто добавить.
Но это слово 'slack'...
вторник, 10 ноября 2015 г., 19:18:21 UTC+6 пользователь Harry Zhurov написал:
В контексте программирования оно вообще ни о чем. Это как разговор Равшана и Джамшута. Вроде понятно, но не серьезно, смешно и совершенно ясно, что не родное. Так и со slack. Совершенно неподходящее название функции. Помнится мы так и не придумали ничего лучшего.
Очень хотелось бы его изменить и не смотреть на совместимость. Могу предложить многословное, но достаточно точное название: calc_free_stack_space.
Calc - это чтобы подчеркнуть, что выполняются вычисления, требующие времени. Остальная часть названия и так понятна.
P.S. Откуда у меня эти придирки к словам.
Проект публичный. Документация ведется на английском. Видимо не отрицается продвижение ОСи в буржуйское сообщество.
Но английский у проекта - это русский английский. Для буржуев, хорошо говорящих на нем, это как для нас Равшан/Джамшут. Проект не будет восприниматься серьезно с таким языком.
Документация это полдела. Но если еще и названия функций непонятны, то проект рискует так и остаться лишь в небольшом русскоговорящем сегменте.
P.P.S. Никого не хотел обидеть. У самого с переводом в направлении русский -> английский все очень плохо.
вторник, 10 ноября 2015 г., 19:18:21 UTC+6 пользователь Harry Zhurov написал:
Harry Zhurov
Nov 12, 2015, 6:06:55 AM11/12/15
to scmrt...@googlegroups.com
11.11.2015 9:42, Чуйкин Андрей пишет:
фразы подразумевается смайлик).
Посмотрим на calc_free_stack_space. Начнём с calc. Сразу вопрос: зачем
подчёркивать, что это, типа, вычисляется? Какую полезную информацию это
несёт? Внутри процессора постоянно что-то вычисляется, так надо ли к
каждой функции добавлять префиксом calc_? Кроме того, если вникать, то
выяснится, что эта функция на самом деле ничего не вычисляет, а просто
проверяет - чекает - "хвост" стека. Т.е. более соответствующим
действительности названием было бы
check_free_stack_space();
Но более коротко и не менее понятно было бы просто
free_stack_space();
т.е. из имени функции по семантическим правилам в программировании ясно,
что функция возвращает свободное_стековое_пространство.
Но и тут не всё идеально. Ведь что это за пространство возвращается? Его
можно поиспольовать? Мы знаем, что проверяется размер/количество,
поэтому надо бы это уточнить:
free_stack_space_count();
или даже лучше:
free_stack_space_size();
Длинновато и не элегантно. Похоже, что space тут вообще лишнее, вот
такой вариант уже почти хорош:
free_stack_size();
Да, три недлинных слова, хороший, читабельный и, вроде, понятный
идентификатор. Но есть одно "но": что может понять из него человек,
который видит это имя в первый раз? Понятно что - функция возвращает
размер свободного места в стеке. Т.е. вызвал её из функции slon(),
получил, например, размер 100 байт, а вызывал из функции mamont(),
получил размер 120 байт (потому что мамонт, пусть, меньше стека потребляет).
К чему я всё это написал? К тому, что выбор имени вообще непростая
задача и тут пресс вариантов, выбирать, оценивать, спорить можно до
бесконечности.
[smile mode off]
Возвращаясь к названию идентификатора. Т.е. имя хорошее, но сходу вводит
в заблуждение, не отражает сути. Ровно так же, как и все перебранные
выше варианты. Надо ведь тут подчеркнуть, что не просто свободный размер
возвращается, а размер области, куда ни одна функция ни разу не достала.
И вот как это коротко, ясно и красиво описать?
Я думал над этим вопросом ещё тогда, когда делался нынешний вариант,
т.е. в релизе версии 4. И все эти free, stack, space, count, size и
прочие более-менее устоявшиеся в качестве терминов слова рассматривал,
перебирал... Ничего внятного, точного и эстетичного, другими словами -
адекватного, не придумалось.
И тогда я вспомнил про термин slack. Это слово в качестве термина очень
широко применяется в области проектирования цифровой техники
(ПЛИСоводво, ASIC'остроение - HDL/FPGA/ASIC Design), а именно в
статическом временном анализе (STA). Там оно служит для обозначения
запаса по времени при оценке быстродействия.
Когда я столкнулся с этим в первый раз, то оно меня озадачило, я не знал
этого слова (никогда до этого не попадалось). Полез в словарь, там перевод:
1) провисшая верёвка; слабина
Take up the slack of a rope! — Подтяни провисшую часть каната!
2) а) бездействие; безделье, пассивность, инертность
б) ; спад деловой активности; затишье (в торговле)
3) = slack water
4) дефицит, нехватка, недостача
Думаю: "Фигня какая-то, какое отношение это может иметь к времянкам в
ПЛИС?! Какие такие провисшие верёвки? Какие такие бездействие,
пассивность?.." Стал думать, вникать в суть. И понял. Термин
используется именно в смысле "слабина" - запас. В контексте STA это
"слабина"-запас по времени - т.е. сколько ещё остаётся нано- или
пикосекунд в запасе у сигнала, когда он достиг целевой точки. Т.е. это
разница между заданным временем распространения сигнала и физическим.
Если слак положительный, то сигнал успел (всё хорошо), а величина слака
показывает количественную оценку. Если слак равен 0, то "верёвка"
натянулась - запаса нет. Если слак отрицательный - "верёвка" лопнула,
это фатальное нарушение.
В нашем случае я просто позаимствовал это слово. Это очень точный
термин, он обозначает не величину остатка (времени в STA или стека в
нашем случае), а именно слабину-запас. Честно говоря, я не проверял,
относится ли этот термин к программированию - я подтянул его просто по
смыслу, по аналогии из STA. Обсуждая вчера в личке с Антоном
адекватность этого термина, получил от него нагугленную ссылку:
http://universal_en_ru.academic.ru/259476/RAM_slack
"RAM slack
Компьютерная техника: заполнитель ОЗУ (Это может быть любая информация,
сформированная, просматривавшаяся или преобразованная со времени
последней загрузки компьютера)"
Оказалось, что имеется и некая корреляция. Это те данные, которыми
заполняется память.
Вчера же провёл небольшой опрос среди знакомых: спросил, что они могут
понять из этого имени функции stack_slack(), что она делает/возвращает.
Оказалось, что почти все никогда раньше этого слова не встречали,
полезли в словари. Два человека дали почти правильный ответ: "прострел
стека". На вопрос, насколько этот термин помогает понять суть среди
русскоязычных пользователей и среди англоязычных, мнение было такое: у
русскоязычных есть проблема - они слова не знают, а вот англоговорящие,
скорее всего, проблем не испытают - они слово не анализируют, они его
знают и просто чувствуют его смысл в конкретном контексте.
Итого, как и прежде считаю смысл термина адекватным, удалять из проекта
не хочу. Кроме того, удалять его нельзя - ломать совместимость на таком
уровне уже неприемлемо. Одно дело конфиги насчёт путей поправить, совсем
другое - исходный код в рабочих и стабильных проектах.
> P.S. Откуда у меня эти придирки к словам. Проект публичный.
> Документация ведется на английском.
Документация, вообще-то, на русском. Просто есть перевод
(посредственного качества, но уж как смоглось) на английский. Но
разрабатывалась документация и её основной вариант - на русском, что
естественно.
> Видимо не отрицается продвижение
> ОСи в буржуйское сообщество. Но английский у проекта - это русский
> английский. Для буржуев, хорошо говорящих на нем, это как для нас
> Равшан/Джамшут. Проект не будет восприниматься серьезно с таким
> языком. Документация это полдела. Но если еще и названия функций
> непонятны, то проект рискует так и остаться лишь в небольшом
> русскоговорящем сегменте.
Всё так. Достаточно погуглить, и найдётся немало ссылок на англоязычные
ресурсы. То, что качество перевода документации, мягко оставляет,
желать, я в курсе, но на одном из тамошних форумов чел, который освоил
тему, написал, что, дескать, т.к. авторы из России, то дока написана на
рунглише, но, тем не менее, всё понятно и подъёмно.
Теперь что касается тех двух функций:
uint32_t stack_size();
uint32_t stack_max_used();
Раз уж пришлось плотнее погрузиться в эту тему, то посмотрел и на них
пристальнее. В результате прихожу к выводу, что они не нужны.
Первая не нужна, т.к. размер стека известен и без неё - он задаётся
статически один раз. Для удобства можно просто использовать константу.
Вторая функция - это вообще просто "синтаксический сахар", она
возвращает разницу между указанным размером стека и его слаком. Если
нравится такая функция - никто и ничего не мешает её использовать на
уровне проекта. Библиотека ОС должна предоставлять только необходимый
функционал, иначе проект обрастёт несметным количеством подобного кода,
появившимся только ввиду частных предпочтений. Ничего не имею в виду
таких предпочтений и сам всё стараюсь "подпилить" под свои хотелки, но
делаю это в своём частном окружении. Общая либа должна быть аскетичной -
по возможности только необходимое по прямому назначению.
По первой функции предвижу возражение, дескать, она создаёт
безальтернативное удобство - не нужно таскать константы для размеров,
городить массивы констант для обработки в цикле... А тут простая
встраиваемая функция, которая просто возвращает размер, известный на
этапе сборки, т.е. это по сути одна или две инструкции проца, а возможно
- и просто загрузка размера напрямую (раз он известен в точке вызова),
хорошие компиляторы такое давно умеют.
Поэтому я не против того, чтобы включить функцию stack_size() в код
процесса.
--
HZ
> Можно (нужно) и просто добавить. Но это слово 'slack'... В контексте
> программирования оно вообще ни о чем. Это как разговор Равшана и
> Джамшута. Вроде понятно, но не серьезно, смешно и совершенно ясно,
> что не родное. Так и со slack. Совершенно неподходящее название
> функции. Помнится мы так и не придумали ничего лучшего. Очень
> хотелось бы его изменить и не смотреть на совместимость. Могу
> предложить многословное, но достаточно точное название:
> calc_free_stack_space. Calc - это чтобы подчеркнуть, что выполняются
> вычисления, требующие времени. Остальная часть названия и так
> понятна.
Слово не нравится... :) Ладно, давай поговорим о словах (в конце каждой
> программирования оно вообще ни о чем. Это как разговор Равшана и
> Джамшута. Вроде понятно, но не серьезно, смешно и совершенно ясно,
> что не родное. Так и со slack. Совершенно неподходящее название
> функции. Помнится мы так и не придумали ничего лучшего. Очень
> хотелось бы его изменить и не смотреть на совместимость. Могу
> предложить многословное, но достаточно точное название:
> calc_free_stack_space. Calc - это чтобы подчеркнуть, что выполняются
> вычисления, требующие времени. Остальная часть названия и так
> понятна.
фразы подразумевается смайлик).
Посмотрим на calc_free_stack_space. Начнём с calc. Сразу вопрос: зачем
подчёркивать, что это, типа, вычисляется? Какую полезную информацию это
несёт? Внутри процессора постоянно что-то вычисляется, так надо ли к
каждой функции добавлять префиксом calc_? Кроме того, если вникать, то
выяснится, что эта функция на самом деле ничего не вычисляет, а просто
проверяет - чекает - "хвост" стека. Т.е. более соответствующим
действительности названием было бы
check_free_stack_space();
Но более коротко и не менее понятно было бы просто
free_stack_space();
т.е. из имени функции по семантическим правилам в программировании ясно,
что функция возвращает свободное_стековое_пространство.
Но и тут не всё идеально. Ведь что это за пространство возвращается? Его
можно поиспольовать? Мы знаем, что проверяется размер/количество,
поэтому надо бы это уточнить:
free_stack_space_count();
или даже лучше:
free_stack_space_size();
Длинновато и не элегантно. Похоже, что space тут вообще лишнее, вот
такой вариант уже почти хорош:
free_stack_size();
Да, три недлинных слова, хороший, читабельный и, вроде, понятный
идентификатор. Но есть одно "но": что может понять из него человек,
который видит это имя в первый раз? Понятно что - функция возвращает
размер свободного места в стеке. Т.е. вызвал её из функции slon(),
получил, например, размер 100 байт, а вызывал из функции mamont(),
получил размер 120 байт (потому что мамонт, пусть, меньше стека потребляет).
К чему я всё это написал? К тому, что выбор имени вообще непростая
задача и тут пресс вариантов, выбирать, оценивать, спорить можно до
бесконечности.
[smile mode off]
Возвращаясь к названию идентификатора. Т.е. имя хорошее, но сходу вводит
в заблуждение, не отражает сути. Ровно так же, как и все перебранные
выше варианты. Надо ведь тут подчеркнуть, что не просто свободный размер
возвращается, а размер области, куда ни одна функция ни разу не достала.
И вот как это коротко, ясно и красиво описать?
Я думал над этим вопросом ещё тогда, когда делался нынешний вариант,
т.е. в релизе версии 4. И все эти free, stack, space, count, size и
прочие более-менее устоявшиеся в качестве терминов слова рассматривал,
перебирал... Ничего внятного, точного и эстетичного, другими словами -
адекватного, не придумалось.
И тогда я вспомнил про термин slack. Это слово в качестве термина очень
широко применяется в области проектирования цифровой техники
(ПЛИСоводво, ASIC'остроение - HDL/FPGA/ASIC Design), а именно в
статическом временном анализе (STA). Там оно служит для обозначения
запаса по времени при оценке быстродействия.
Когда я столкнулся с этим в первый раз, то оно меня озадачило, я не знал
этого слова (никогда до этого не попадалось). Полез в словарь, там перевод:
1) провисшая верёвка; слабина
Take up the slack of a rope! — Подтяни провисшую часть каната!
2) а) бездействие; безделье, пассивность, инертность
б) ; спад деловой активности; затишье (в торговле)
3) = slack water
4) дефицит, нехватка, недостача
Думаю: "Фигня какая-то, какое отношение это может иметь к времянкам в
ПЛИС?! Какие такие провисшие верёвки? Какие такие бездействие,
пассивность?.." Стал думать, вникать в суть. И понял. Термин
используется именно в смысле "слабина" - запас. В контексте STA это
"слабина"-запас по времени - т.е. сколько ещё остаётся нано- или
пикосекунд в запасе у сигнала, когда он достиг целевой точки. Т.е. это
разница между заданным временем распространения сигнала и физическим.
Если слак положительный, то сигнал успел (всё хорошо), а величина слака
показывает количественную оценку. Если слак равен 0, то "верёвка"
натянулась - запаса нет. Если слак отрицательный - "верёвка" лопнула,
это фатальное нарушение.
В нашем случае я просто позаимствовал это слово. Это очень точный
термин, он обозначает не величину остатка (времени в STA или стека в
нашем случае), а именно слабину-запас. Честно говоря, я не проверял,
относится ли этот термин к программированию - я подтянул его просто по
смыслу, по аналогии из STA. Обсуждая вчера в личке с Антоном
адекватность этого термина, получил от него нагугленную ссылку:
http://universal_en_ru.academic.ru/259476/RAM_slack
"RAM slack
Компьютерная техника: заполнитель ОЗУ (Это может быть любая информация,
сформированная, просматривавшаяся или преобразованная со времени
последней загрузки компьютера)"
Оказалось, что имеется и некая корреляция. Это те данные, которыми
заполняется память.
Вчера же провёл небольшой опрос среди знакомых: спросил, что они могут
понять из этого имени функции stack_slack(), что она делает/возвращает.
Оказалось, что почти все никогда раньше этого слова не встречали,
полезли в словари. Два человека дали почти правильный ответ: "прострел
стека". На вопрос, насколько этот термин помогает понять суть среди
русскоязычных пользователей и среди англоязычных, мнение было такое: у
русскоязычных есть проблема - они слова не знают, а вот англоговорящие,
скорее всего, проблем не испытают - они слово не анализируют, они его
знают и просто чувствуют его смысл в конкретном контексте.
Итого, как и прежде считаю смысл термина адекватным, удалять из проекта
не хочу. Кроме того, удалять его нельзя - ломать совместимость на таком
уровне уже неприемлемо. Одно дело конфиги насчёт путей поправить, совсем
другое - исходный код в рабочих и стабильных проектах.
> P.S. Откуда у меня эти придирки к словам. Проект публичный.
> Документация ведется на английском.
(посредственного качества, но уж как смоглось) на английский. Но
разрабатывалась документация и её основной вариант - на русском, что
естественно.
> Видимо не отрицается продвижение
> ОСи в буржуйское сообщество. Но английский у проекта - это русский
> английский. Для буржуев, хорошо говорящих на нем, это как для нас
> Равшан/Джамшут. Проект не будет восприниматься серьезно с таким
> языком. Документация это полдела. Но если еще и названия функций
> непонятны, то проект рискует так и остаться лишь в небольшом
> русскоговорящем сегменте.
ресурсы. То, что качество перевода документации, мягко оставляет,
желать, я в курсе, но на одном из тамошних форумов чел, который освоил
тему, написал, что, дескать, т.к. авторы из России, то дока написана на
рунглише, но, тем не менее, всё понятно и подъёмно.
Теперь что касается тех двух функций:
uint32_t stack_size();
uint32_t stack_max_used();
Раз уж пришлось плотнее погрузиться в эту тему, то посмотрел и на них
пристальнее. В результате прихожу к выводу, что они не нужны.
Первая не нужна, т.к. размер стека известен и без неё - он задаётся
статически один раз. Для удобства можно просто использовать константу.
Вторая функция - это вообще просто "синтаксический сахар", она
возвращает разницу между указанным размером стека и его слаком. Если
нравится такая функция - никто и ничего не мешает её использовать на
уровне проекта. Библиотека ОС должна предоставлять только необходимый
функционал, иначе проект обрастёт несметным количеством подобного кода,
появившимся только ввиду частных предпочтений. Ничего не имею в виду
таких предпочтений и сам всё стараюсь "подпилить" под свои хотелки, но
делаю это в своём частном окружении. Общая либа должна быть аскетичной -
по возможности только необходимое по прямому назначению.
По первой функции предвижу возражение, дескать, она создаёт
безальтернативное удобство - не нужно таскать константы для размеров,
городить массивы констант для обработки в цикле... А тут простая
встраиваемая функция, которая просто возвращает размер, известный на
этапе сборки, т.е. это по сути одна или две инструкции проца, а возможно
- и просто загрузка размера напрямую (раз он известен в точке вызова),
хорошие компиляторы такое давно умеют.
Поэтому я не против того, чтобы включить функцию stack_size() в код
процесса.
--
HZ
Anton Gusev
Nov 12, 2015, 6:45:12 AM11/12/15
to scmrt...@googlegroups.com
Harry Zhurov пишет 12.11.2015 16:06:
> Поэтому я не против того, чтобы включить функцию stack_size() в код
> процесса.
Да, stack_size() была бы очень удобна. В идеале бы виртуальную функцию в
TBaseProcess, переопределяемую в каждом процессе. Чтобы можно было в
цикле получать:
for(uint_fast8_t i = 0; i < OS::PROCESS_COUNT; i++)
{
uint32_t cpu = profiler.get_result(i);
uart << OS::TPriority(i) << '\t'
<< OS::get_proc(i)->stack_slack() << " of "
<< OS::get_proc(i)->stack_size() << '\t'
<< (double)cpu / 100 << "\r\n";
}
Но это, наверное, чересчур - возрастёт расход памяти.
Можно добавить таблицу размеров стека по аналогии с ProcessTable
class TKernel {
...
static size_t StackSizeTable[PROCESS_COUNT];
и инициализировать её в конструкторах процессов. Тогда функцию
stack_size() можно сделать невиртуальной в TBaseProcess.
Ну или просто функцию process<>::stack_size() { return stack_size; }
ЗЫ. Насчёт stack_slack() - я не знал этого слова, но, погуглив немного,
узнал. Думаю, что это вполне подходящий термин. Нужна именно семантика
запаса.
> Поэтому я не против того, чтобы включить функцию stack_size() в код
> процесса.
TBaseProcess, переопределяемую в каждом процессе. Чтобы можно было в
цикле получать:
for(uint_fast8_t i = 0; i < OS::PROCESS_COUNT; i++)
{
uint32_t cpu = profiler.get_result(i);
uart << OS::TPriority(i) << '\t'
<< OS::get_proc(i)->stack_slack() << " of "
<< OS::get_proc(i)->stack_size() << '\t'
<< (double)cpu / 100 << "\r\n";
}
Но это, наверное, чересчур - возрастёт расход памяти.
Можно добавить таблицу размеров стека по аналогии с ProcessTable
class TKernel {
...
static size_t StackSizeTable[PROCESS_COUNT];
и инициализировать её в конструкторах процессов. Тогда функцию
stack_size() можно сделать невиртуальной в TBaseProcess.
Ну или просто функцию process<>::stack_size() { return stack_size; }
ЗЫ. Насчёт stack_slack() - я не знал этого слова, но, погуглив немного,
узнал. Думаю, что это вполне подходящий термин. Нужна именно семантика
запаса.
Чуйкин Андрей
Nov 19, 2015, 4:45:20 AM11/19/15
to scmrtos-ru
Привет.
В develop добавлены:
1. Рекурсивный мьютекс, как расширение. Также в os_service.h добавлен шаблонный TScopedLock для произвольных мьютексов. TMutexLocker объявлен уже через TScopedLock.
2. В базовый класс процесса добавлена функция stack_size()/rstack_size(), возвращающая размер стека для процесса.
Прошу сделать ревизию кода.
Reply all
Reply to author
Forward
0 new messages