Brief description of new features and changes in version 5.5.8

1. What’s new in SObjectizer-5.5.8
SObjectizer Team, Aug 2015
A Short Overview

2. There are several new features in SObjectizer v.5.5.8.
They can be divided into two groups:
● agent’s priorities and three new dispatchers with priorities
support,
● simplification of working with ad-hoc agents.
This presentation briefly describes them.
SObjectizer Team, Aug 2015

3. Agent’s priorities and new dispatchers
SObjectizer Team, Aug 2015

4. Since v.5.5.8 every agent has a priority.
Priority is just an optional mark for dispatchers.
Some dispatchers can use this mark to do some specific
event processing with respect to agent’s priorities.
Some dispatchers do not use this mark (all old dispatchers
like one_thread or thread_pool ignore priorities).
SObjectizer Team, Aug 2015

5. Only eight priorities are available.
Priorities are given as enumeration so_5::priority_t with
members like p0, ..., p7.
Priority so_5::priority_t::p0 is the lowest.
Priority so_5::priority_t::p7 is the highest.
SObjectizer Team, Aug 2015

6. Priority can be specified during agent construction via
context_t object:
class my_agent : public so_5::rt::agent_t
{
public :
my_agent( context_t ctx )
: so_5::rt::agent_t( ctx + so_5::priority_t::p6 )
...
};
Once assigned the agent’s priority cannot be changed.
By default all agents have priority so_5::priority_t::p0.
SObjectizer Team, Aug 2015

7. Old dispatchers, like one_thread, active_obj, active_group,
thread_pool and adv_thread_pool do not support agent’s
priorities.
It means that those dispatchers will ignore priorities of
agents during events processing.
But there are three new dispatchers which understand agent’
s priorities and implement different events handling policies.
SObjectizer Team, Aug 2015

8. New dispatchers are divided into two groups:
1. prio_one_thread.
2. prio_dedicated_threads.
SObjectizer Team, Aug 2015

9. Group prio_one_thread consists of two dispatchers.
They do processing of events of all priorities on the same
working thread.
Those dispatchers are defined inside so_5::disp::
prio_one_thread namespace.
SObjectizer Team, Aug 2015

10. Dispatcher prio_one_thread::strictly_ordered maintains
event queue where all events are strictly ordered from
highest priority to lowest.
An event with lower priority cannot be handled if there are
some events with higher priorities.
Events with the same priority are ordered in chronological
order.
SObjectizer Team, Aug 2015

11. Dispatcher prio_one_thread::queued_round_robin maintains
several event queues: one for every priority.
This dispatcher handles no more than Q7 events of priority
p7, then no more than Q6 events of priority p6 and so on.
Values of Q7, Q6, …, Q0 can be configured during creation
of dispatcher instance.
SObjectizer Team, Aug 2015

12. Group prio_dedicated_threads consists of just one
dispatcher.
This dispatcher creates a dedicated thread for every priority.
It means that there are eight working threads and events
with different priorities are handled on different threads.
This dispatcher is defined inside so_5::disp::
prio_dedicated_threads::one_per_prio namespace.
SObjectizer Team, Aug 2015

13. Different priority-respected dispatchers can be used in
different circumstances.
SObjectizer Team, Aug 2015

14. prio_one_thread::strictly_ordered dispatcher can be used
when there is a need to handle some event as soon as
possible.
For example, agent task_processor with priority p0 handles
messages task_requests.
Another agent, processor_config with priority p1 handles
message new_config with new parameters for task
processing.
SObjectizer Team, Aug 2015

15. Agents task_processor and processor_config could share
some common data (like configuration parameters block).
They can access and modify that shared data without the
need of data synchronization because they work on the
same working thread.
SObjectizer Team, Aug 2015

16. prio_one_thread::queued_round_robin dispatcher can be
used when it is necessary to ensure progress in handling
requests with different priorities.
For example there could be thousands of read-data requests
from data-readers and hundreds of update-data requests
from data-writers.
It is possible to assign p1 and quote 100 for agents for
serving read-data requests. Agents for serving update-data
request could have p0 and quote 10.
SObjectizer Team, Aug 2015

17. prio_dedicated_threads::one_per_prio dispatcher can be
used when it is necessary to provide different context for
different types of work.
For example there could be very heavyweight requests like
image transformation and very lightweight requests like
asking image’s metadata.
Lightweight requests could be handled by agents with higher
priorities and heavyweight request -- by agents with lower
priorities.
SObjectizer Team, Aug 2015

18. More detailed information about agent’s priorities and three
new dispatcher can be found in Project’s Wiki.
There are also three new examples in SObjectizer
distribution: machine_control, news_board and
prio_work_stealing. They show usage of new dispatchers.
SObjectizer Team, Aug 2015

19. Simplification of work with ad-hoc agents
SObjectizer Team, Aug 2015

20. There are several small improvements in work with ad-hoc
agents. But the total effect of them is a significant
simplification of ad-hoc agents usage.
SObjectizer Team, Aug 2015

21. It is possible to specify agent_context for ad-hoc agent. It
allows to assign not only a priority for ad-hoc agent but also
other stuff like message limits:
env.introduce_coop( []( so_5::rt::agent_coop_t & coop ) {
auto a = coop.define_agent( coop.make_agent_context()
// Priority for ad-hoc agent.
+ so_5::priority_t::p7
// Message limits.
+ so_5::rt::agent_t::limit_then_drop< get_status >( 1 )
+ so_5::rt::agent_t::limit_then_abort< task_request >( 1000 ) );
...
} );
SObjectizer Team, Aug 2015

22. Also it is possible to use ad-hoc agent proxy instead of ad-
hoc agent’s direct mbox.
For example, in agent subscription:
auto a = coop.define_agent();
// v.5.5.8 way:
a.event< get_status >( a, []{...} );
// Pre v.5.5.8 way:
a.event< get_status >( a.direct_mbox(), []{...} );
SObjectizer Team, Aug 2015

23. Or for messages sending:
using namespace std::chrono;
auto a = coop.define_agent();
// v.5.5.8 way:
so_5::sent_to_agent< get_status >( a );
so_5::send_delayed_to_agent< get_status >( a, milliseconds... );
so_5::send_periodic_to_agent< get_status >( a, milliseconds... );
// Pre v.5.5.8 way:
so_5::send_to_agent< get_status >( a.direct_mbox() );
so_5::send_delayed_to_agent< get_status >( a.direct_mbox(), milliseconds... );
so_5::send_periodic_to_agent< get_status >( a.direct_mbox(), milliseconds... );
SObjectizer Team, Aug 2015

24. Creation of children coops simplified. Reference to
agent_coop_t object can be used instead of the coop name.
env.introduce_coop( []( so_5::rt::agent_coop_t & parent ) {
parent.define_agent()
.on_start( [&parent]{
parent.environment().introduce_child_coop( parent,
[]( so_5::rt::agent_coop_t & child ) {
child.define_agent()...
} );
...
} );
...
} );
SObjectizer Team, Aug 2015

25. New methods for coop deregistration are added to
agent_coop_t:
env.introduce_coop( []( so_5::rt::agent_coop_t & coop ) {
coop.define_agent()
.event< finish_work >( some_mbox, [&coop] {
// v.5.5.8 way:
coop.deregister_normally();
// Pre v.5.5.8 way:
coop.environment().deregister_coop(
coop.query_coop_name(),
so_5::rt::dereg_reason::normal );
} )
...
} );
SObjectizer Team, Aug 2015

26. The full list of changes in v.5.5.8 with more deep
explanations can be found in the corresponding section of
Project’s Wiki.
SObjectizer Team, Aug 2015

27. Additional Information:
Project’s home: http://sourceforge.net/projects/sobjectizer
Documentation: http://sourceforge.net/p/sobjectizer/wiki/
Forum: http://sourceforge.net/p/sobjectizer/discussion/
Google-group: https://groups.google.com/forum/#!forum/sobjectizer
GitHub mirror: https://github.com/masterspline/SObjectizer