In some cases it's useful to create processes in run-time.
Examples: to execute a menu's item function,
a code sharing (several processes use the same code).
Dynamic process management is not currently planned.The reason for this is the following: main dynamic process management advantages are achieved with "true" dynamic memory management (DMM); dynamic memory management in single-ship uCs is poor because of few ammount of memory and lack of suitable DMM support (such as garbage collection, defragmentation, etc.). So, in fact, dynamic process management in singe-chip uCs can be carried out only based on static memory allocation. Therefore, different processes will utilize the same memory (for process data and stack[s]) - that is actually all these "different" processes are the same (one) process.
Thus, taking into account the above, dynamic process management causes complication and overhead only.
To achieve the goal the single process can be used with various function calls. The function calls will "emulate" "different" process launching.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let's select two approaches: dynamic process management (DPM), and a code sharing.
1. To obtain 'Code sharing' it's no need to implement the DPM in scmRTOS.
For this, the BaseProcess::Exec() 'static' method must be renamed to 'virtual'.
This allows to create a fixed number of processes with the same Exec() method. To 'differ' the processes, a parameter passing (into process) has to been implemented also.
This all will be done in compile time, so there are no exceptional costs in run-time.
2. Usually the DPM implies 'new/delete' calls, which are really very expensive for embedded use.
No doubt this is need where unknown number of processes may be created. We have more simple systems. There is a fixed number of process in systems. So the memory for both processes' data and stacks may be allocated statically. Great question - how to manage them in C++? I don't know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. scmRTOS based on static object allocation, static linkage and static type checking. This provides the key features of the RTOS: simplicity, speed and safety. The using of "virtual" processes, at least, causes notable overhead in kernel's code and continuous critical sections. At the same time, "virtual" processes do not bring new functionaly, do not reduce execution time, do not simplify the using of the RTOS.
2. The answer was given in my previous comment.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1671124
Originator: NO
Dynamic process management is not currently planned.The reason for this is the following: main dynamic process management advantages are achieved with "true" dynamic memory management (DMM); dynamic memory management in single-ship uCs is poor because of few ammount of memory and lack of suitable DMM support (such as garbage collection, defragmentation, etc.). So, in fact, dynamic process management in singe-chip uCs can be carried out only based on static memory allocation. Therefore, different processes will utilize the same memory (for process data and stack[s]) - that is actually all these "different" processes are the same (one) process.
Thus, taking into account the above, dynamic process management causes complication and overhead only.
To achieve the goal the single process can be used with various function calls. The function calls will "emulate" "different" process launching.
Logged In: YES
user_id=1671105
Originator: YES
Let's select two approaches: dynamic process management (DPM), and a code sharing.
1. To obtain 'Code sharing' it's no need to implement the DPM in scmRTOS.
For this, the BaseProcess::Exec() 'static' method must be renamed to 'virtual'.
This allows to create a fixed number of processes with the same Exec() method. To 'differ' the processes, a parameter passing (into process) has to been implemented also.
This all will be done in compile time, so there are no exceptional costs in run-time.
2. Usually the DPM implies 'new/delete' calls, which are really very expensive for embedded use.
No doubt this is need where unknown number of processes may be created. We have more simple systems. There is a fixed number of process in systems. So the memory for both processes' data and stacks may be allocated statically. Great question - how to manage them in C++? I don't know.
Logged In: YES
user_id=1671124
Originator: NO
1. scmRTOS based on static object allocation, static linkage and static type checking. This provides the key features of the RTOS: simplicity, speed and safety. The using of "virtual" processes, at least, causes notable overhead in kernel's code and continuous critical sections. At the same time, "virtual" processes do not bring new functionaly, do not reduce execution time, do not simplify the using of the RTOS.
2. The answer was given in my previous comment.