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.

SObjectizer Team, Aug 2015

Agent’s priorities and new dispatchers

SObjectizer Team, Aug 2015

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

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

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

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

New dispatchers are divided into two groups:

1. prio_one_thread.2. prio_dedicated_threads.

SObjectizer Team, Aug 2015

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

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

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

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

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

SObjectizer Team, Aug 2015

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

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

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

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

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

Simplification of work with ad-hoc agents

SObjectizer Team, Aug 2015

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

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

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

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

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

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

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

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