caxapa.ru :: вы понимаете, что потоки в контроллере практически всегда имеют сильные взаимосвязи по данным между собой.

Mahagam (30.10.2013 11:05, просмотров: 450) ответил Операционная система на Операционная система обязана Каждому процессу предоставить ИЗОЛИРОВАННЫЕ стек и сегменты данных. Даже прерывания могут быть организованы как ЗАДАЧА - т.е. аппаратное переключение контекста (сохранение регистров) и переключение указателя на СВОЙ

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

Ответить

- Нужно измерить реальный расход под стек? Ну так измерьте его! - SS:ESP(30.10.2013 11:16, )
- Если рассмативать RTOS как переключалку задач, тогда конечно, легальных методов нет. А вообще, большинство сервисов для этого и предназначены - семафоры, флаги, очереди сообщений. Мютексом в конце концов можно доступ к расшаренной памяти обернуть. Alex B.(108 знак., 30.10.2013 11:11)
  - if (current_stack_pointer<deepest_bottom){deepest_bottom=current_stack_pointer;} Всралась очипятка - SS:ESP(30.10.2013 11:27, )
  - if (current_stack_pointer<deepest_bottom)(deepest_bottom=current_stack_pointer;) Где что должно аццки тормозить? - SS:ESP(30.10.2013 11:22, )
    - Deepest bottom? Надо же было так обозвать :-))) - SciFi(30.10.2013 11:27)
      - Я просто к тому, что у англоязычных могут возникнуть самые разнообразные ассоциации, и стек вряд ли будет среди них :-) Low limit получше будет. - SciFi(30.10.2013 13:57)
        
        Я бы на их месте подумал, что "low limit"=="нихт бабкен" :-) - SS:ESP(30.10.2013 14:05, )
      - Ибо стек растёт вниз! Потому и "глубочайшее дно" - SS:ESP(30.10.2013 11:28, )
        
        В контроллерах проф. уроня -- растёт вверх. Вообще-то не в каждой задаче, а перед вызовом каждой функции (если в стеке свободно менее N -- создать новый стек и вызвать функцию в новом стеке, например). Тяжеловатый подход... - fk0(30.10.2013 11:33)
        
        Для "проф?"контроллеров всё наоборот - if (current_stack_pointer>highest_top){highest_top=current_stack_pointer;} - SS:ESP(30.10.2013 11:42, )
        
        Тяжеловатый? Эффективный! Сначала задать размер стека заведомо большим, затем измерить. Задать размер стека по реальному расходу + небольшой запас - SS:ESP(30.10.2013 11:40, )
        
        Вот небольшого запаса однажды и не хватит (не все варианты работы программы можно измерить). Поэтому игрища со стеком с точным измерением, вместо того, чтоб попросту домножить на Pi^2, мне кажутся сомнительным занятием. - fk0(30.10.2013 11:42)
        
        Или внутри функций проверять а не маловат ли запас? Может попросить операционную систему какой-нибудь malloc() - SS:ESP(30.10.2013 11:48, )
        
        Внутри вызванной функции, если маловат -- что делать? Только abort() и остаётся. Стек уже не переместишь (в нём locals и arguments). А в вызывающей функции вместо call вполне можно сделать перемену стека и call функции в новом стеке. - fk0(30.10.2013 12:26)
        
        abort() только в случае if(malloc(4096)==NULL){exit(1);} Тогда уж больше некуда. Соответственно или редизайн, или толще камень - SS:ESP(30.10.2013 14:02, )
        
        Для особо тормознутых x86-х повторяю: стек изменить внутри вызывемой функции практически невозможно, ввиду очевидных трудностей с адресуемостью, после, аргументов функции (в старом стеке) и переменных функции (разорванных между старым и новым fk0(185 знак., 30.10.2013 14:52)
        
        Не обязательно, хотя сложнее работать с аргументами. Сохранить текущий sp, попросить новый блок памяти, загрузить новый sp, юзать, перед выходом освободить блок, вернуть старый sp. - SS:ESP(30.10.2013 13:46, )
        
        Замечтельно. Но как в новом стеке получить доступ к аргументам и переменным функции в _старом_. И как быть, что теперь часть переменных у нас в новом стеке, а часть в старом. Невозможно! Только если это всё проделать в прологе функции и, fk0(486 знак., 30.10.2013 14:04)
        
        А разве в прототипе функции не указывается количество и тип аргументов ?-) Или функция должна угадать количество pop перед ret ?-) - SS:ESP(30.10.2013 14:20, )
        
        Для функций с переменным числом аргументов pop будет делать тот кто вызывал. Поэтому не указывается. В паскале обратный порядок передачи аргументов в функцию, поэтому у них вовсе нет таких функций и невозможно на паскале написать функцию Writeln fk0(31 знак., 30.10.2013 14:53)
        
        Метки и переходы запретить! Кто не согласен, того на костер! - Облез Паскаль(30.10.2013 22:04, )
        
        Не надо дублировать аргументы в новом стеке, нужно знать адресную арифметику конкретного компилятора. Не сложно, но заморочено Ж-( - SS:ESP(30.10.2013 14:20, )
        
        Конечно проверять размер остатка стека сразу в начале функции и адресовать аргументы через вспомогательный указатель - не айс - SS:ESP(30.10.2013 14:21, )
        
        Например для потоков использовать единственный аргумент - указатель на структуру с полным фаршем переменных и аргументов - SS:ESP(30.10.2013 14:22, )
        
        Это какой-то альтернативный компилятор не-C из альтернативной вселенной. Разговор ни о чём. - fk0(30.10.2013 14:54)
        
        Указатель, структура - более чем C. Один аргумент - не надо ничего копировать между стеками - SS:ESP(30.10.2013 15:02, )
        
        Это уже какой-то словесный понос. Вот практический пример: как быть в случае printf("hello world %u %u %u %u %u...", 1,2,3,4,5,6,....100500....) ? И один аргумент может передаваться в стеке: void f(...) и f(1) потом. Или если gcc -O0 - fk0(30.10.2013 15:07)
        
        Практический ответ для любого компилятора: резервируете где хотите область памяти для строки желаемого формата (хоть с китайским %s), также область памяти под массив указателей на переменные к печати. Ну сами переменные, я надеюсь это понятно. SS:ESP(161 знак., 30.10.2013 15:28, )
        
        Покажите где ранее я сказал, что ЛЮБОЙ функции достаточно единственного аргумента? - SS:ESP(30.10.2013 15:27, )
        
        Понятно. Тролля лучше не кормить. - fk0(30.10.2013 15:42)
        
        Реализация описанного - работа и ответственность программиста. Не компилятора - SS:ESP(30.10.2013 16:02, )
        
        Если размер оперативной памяти стремится к бесконечности, можно умножить реальный расход на гугол :-) - SS:ESP(30.10.2013 11:47, )

Средства и методы разработки