What’s new in SObjectizer 5.5.8

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

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.

Agent’s priorities and new dispatchers

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).

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.

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.

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.

New dispatchers are divided into two groups:
1. prio_one_thread.
2. prio_dedicated_threads.

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.

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.

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.

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.

Different priority-respected dispatchers can be used in
different circumstances.

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.

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.

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.

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.

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.

Simplification of work with ad-hoc agents

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.

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 ) );
...
} );

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(), []{...} );

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... );

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()...
} );
...
} );
...
} );

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 );
} )
...
} );

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.

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

What’s new in SObjectizer 5.5.8

More Related Content

More from Yauheni Akhotnikau (19)

Recently uploaded (20)

What’s new in SObjectizer 5.5.8