We are thinking of complementing Pharos with a new feature: "Future".
This will have functionality similar to the "Future" class in Java SE. We currently believe that this is a very useful feature for many applications, particularly for distributed systems.
For example, suppose you have a thread that needs to communicate with several remote systems simultaneously and wait for a response. In a typical scenario you could send a request to each one of them and wait for the reply. If you have many remote systems, having to wait for a reply before communicating with next system is a huge waste of time.
Instead, with "Future" feature, your thread could send messages to every remote system, and after all messages have been sent you could block your thread on the first "Future" that will have a reply.
The details are under analysis (we are currently continuing with the port for Cortex-M4) but is looking promising to be the next step.
Thanks,
Pharos team
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are now thinking of supporting multi-core in Pharos. This new support is not intended provide an "uncontrolled" SMP environment. Instead, keeping inline with the vision of Pharos, we intend to have a well-behaved with a configurable-interference system between cores. That is, it will not be possible to a core to overload another core with inter-core interrupts (needed to communicate between cores).
We are working out the details of which services will be available to communicate between cores. In principle:
- each partition will be assigned to a single core (including all of the partition threads, semaphores, queues, etc)
- each core can have multiple partitions
- each partition will be able to communicate with another partition on a different core through hw queues and channels.
We are now going on vacations so the new release (2.0.0) may a little longer to be published.
See ya,
Pharos team
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
STM32 board port (1.6.0) is almost finished and we are starting to focus now on the next release.
We are shifting our goals from porting Pharos to new boards to adding more features to it. We are now considering adding a WCET property to the aperiodic threads as well. This was something that was missing in time protection feature of Pharos. Hopefully, this will be solved soon.
We are also thinking of adding new features, such as:
- delayed partition initialization (initializing a partition when possible so that the system can start extremely fast if only a few partitions need to be initialized)
- multi-core communication -> right now we have AMP support but we plan to allow partitions from different cores to communicate with each other in a controlled fashion. More details about this will come later on
- dynamic memory support -> even though Pharos does NOT require any kind of dynamic memory, we plan to give the partitions some sort of dynamic memory, like malloc's. This will be done in a controlled manner to not introduce unpredictable delays (at most will be O(Log(N) where N is the total amount of memory available)
Other features are also inline and we will keep you posted as we develop them. We are still not sure how many new features will be on the next release, but we feel very confident that at least the extension of WCET for aperiodic threads will be supported.
See you soon,
Pharos team
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are now working on release 3.0.0. It will improve the multicore capabilities of Pharos. Instead of being purely AMP (that is, each core runs independently from each other with no synchronization/communication supported by Pharos) we will use a new "RMP" (Real-time MultiProcessing).
This new RMP concept is distint from AMP or SMP in the sense it only allows controllable and bounded interference from one core to another. In this fashion, Pharos will now allow for Heavy Queue and Channels to transfer information from one core to another. It will be possible for a thread in one core to block waiting to process incoming messages (2-copy heavy weight messages or zero-copy channel bulks) from another core.
Besides this new feature, bugs will be corrected and maybe some other features will be added.
See you soon,
Pharos team
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello all,
We are thinking of complementing Pharos with a new feature: "Future".
This will have functionality similar to the "Future" class in Java SE. We currently believe that this is a very useful feature for many applications, particularly for distributed systems.
For example, suppose you have a thread that needs to communicate with several remote systems simultaneously and wait for a response. In a typical scenario you could send a request to each one of them and wait for the reply. If you have many remote systems, having to wait for a reply before communicating with next system is a huge waste of time.
Instead, with "Future" feature, your thread could send messages to every remote system, and after all messages have been sent you could block your thread on the first "Future" that will have a reply.
The details are under analysis (we are currently continuing with the port for Cortex-M4) but is looking promising to be the next step.
Thanks,
Pharos team
Hello all,
We are now thinking of supporting multi-core in Pharos. This new support is not intended provide an "uncontrolled" SMP environment. Instead, keeping inline with the vision of Pharos, we intend to have a well-behaved with a configurable-interference system between cores. That is, it will not be possible to a core to overload another core with inter-core interrupts (needed to communicate between cores).
We are working out the details of which services will be available to communicate between cores. In principle:
- each partition will be assigned to a single core (including all of the partition threads, semaphores, queues, etc)
- each core can have multiple partitions
- each partition will be able to communicate with another partition on a different core through hw queues and channels.
We are now going on vacations so the new release (2.0.0) may a little longer to be published.
See ya,
Pharos team
Hello all,
STM32 board port (1.6.0) is almost finished and we are starting to focus now on the next release.
We are shifting our goals from porting Pharos to new boards to adding more features to it. We are now considering adding a WCET property to the aperiodic threads as well. This was something that was missing in time protection feature of Pharos. Hopefully, this will be solved soon.
We are also thinking of adding new features, such as:
- delayed partition initialization (initializing a partition when possible so that the system can start extremely fast if only a few partitions need to be initialized)
- multi-core communication -> right now we have AMP support but we plan to allow partitions from different cores to communicate with each other in a controlled fashion. More details about this will come later on
- dynamic memory support -> even though Pharos does NOT require any kind of dynamic memory, we plan to give the partitions some sort of dynamic memory, like malloc's. This will be done in a controlled manner to not introduce unpredictable delays (at most will be O(Log(N) where N is the total amount of memory available)
Other features are also inline and we will keep you posted as we develop them. We are still not sure how many new features will be on the next release, but we feel very confident that at least the extension of WCET for aperiodic threads will be supported.
See you soon,
Pharos team
Hello all,
We are now working on release 3.0.0. It will improve the multicore capabilities of Pharos. Instead of being purely AMP (that is, each core runs independently from each other with no synchronization/communication supported by Pharos) we will use a new "RMP" (Real-time MultiProcessing).
This new RMP concept is distint from AMP or SMP in the sense it only allows controllable and bounded interference from one core to another. In this fashion, Pharos will now allow for Heavy Queue and Channels to transfer information from one core to another. It will be possible for a thread in one core to block waiting to process incoming messages (2-copy heavy weight messages or zero-copy channel bulks) from another core.
Besides this new feature, bugs will be corrected and maybe some other features will be added.
See you soon,
Pharos team