该系列文章主要记录阅读理解ceph代码时可能遇到的一些难点，可能跳跃比较大。如果有描述错误或任何疑问欢迎交流讨论。
状态机本身机制是比较好理解的，看状态机代码时只要理解几个特殊的地方就很容易。
默认子状态
状态机的部分状态有默认子状态，从该状态到其默认子状态是不需要事件触发的。比如：
struct Primary : boost::statechart::state< Primary, Started, Peering >, NamedState
{
Primary(my_context ctx);
void exit();
typedef boost::mpl::list <
boost::statechart::custom_reaction< ActMap >,
boost::statechart::custom_reaction< MNotifyRec >,
boost::statechart::transition< NeedActingChange, WaitActingChange >
> reactions;
boost::statechart::result react(const ActMap&);
boost::statechart::result react(const MNotifyRec&);
};
这里定义了Primary状态，其父状态是Started，默认子状态是Peering。因而从Primary进入Peering状态不需要任何事件触发。
状态跳转
状态机是由事件驱动的，定义事件的响应方法有2种方式。
- 注册事件处理函数，比如上面Primary在处理ActMap事件就注册了boost::statechart::result react(const ActMap&)函数。
- 跳转到另一个状态。比如上面Primary处理NeedActingChange事件。
在事件处理中直接跳转状态是一种方式。
还有一种状态跳转方式，就是显式的调用transit。比如：
boost::statechart::result PG::RecoveryState::Reset::react(const ActMap&)
{
PG *pg = context< RecoveryMachine >().pg;
...
...
pg->update_heartbeat_peers();
pg->take_waiters();
return transit< Started >();
}
事件处理
注意事件不一定都是在当前状态下处理，如果当前状态处理不了，可以在其父状态处理，相当于子状态继承了父状态的事件处理方法。
这里还有一个小疑问，我们看到有些地方执行post_event, 这些event是什么时候由谁执行的呢？ 可以想象应该是状态机在处理完当前事件之后就开始执行了。查看boost源码也确实如此。
post_event的实现：
void post_event_impl( const event_base_ptr_type & pEvent )
{
BOOST_ASSERT( get_pointer( pEvent ) != 0 );
eventQueue_.push_back( pEvent );
}
eventQueue_是在process_event中循环处理的。
void process_event( const event_base_type & evt )
{
if ( send_event( evt ) == detail::do_defer_event )
{
deferredEventQueue_.push_back( evt.intrusive_from_this() );
}
process_queued_events();
}
void process_queued_events()
{
while ( !eventQueue_.empty() )
{
event_base_ptr_type pEvent = eventQueue_.front();
eventQueue_.pop_front();
if ( send_event( *pEvent ) == detail::do_defer_event )
{
deferredEventQueue_.push_back( pEvent );
}
}
}
有了上面的基础之后，再去找各种状态是怎么变化的就非常简单了。
状态机的事务
还有一点对于理解ceph状态机也比较重要，我们经常看到状态内部执行事务，但是没看到事务在哪里提交。答案在这里：
if (!advance_pg(curmap->get_epoch(), pg, handle, &rctx, &split_pgs))
{
// we need to requeue the PG explicitly since we didn't actually
// handle an event
peering_wq.queue(pg);
}
else
{
assert(!pg->peering_queue.empty());
PG::CephPeeringEvtRef evt = pg->peering_queue.front();
pg->peering_queue.pop_front();
pg->handle_peering_event(evt, &rctx);
}
need_up_thru = pg->need_up_thru || need_up_thru;
same_interval_since = MAX(pg->info.history.same_interval_since,
same_interval_since);
pg->write_if_dirty(*rctx.transaction);
if (!split_pgs.empty())
{
rctx.on_applied->add(new C_CompleteSplits(this, split_pgs));
split_pgs.clear();
}
dispatch_context_transaction(rctx, pg, &handle);
就在最后一行。
然后，好像没了，自己对着状态机那个图研究吧 : )
