boost asio 应用方法学(三)——异步规范

异步模式是 boost asio 的最重要的贡献,所以在接下来,我们会有很多篇幅描述j基于 boost asio 异步编程的方法。

异步模式是一个相当复杂的模式。基础开发实践中,子功能通过函数封装,并通过在栈上一级级调用与返回,完成最终的逻辑功能,这种方式是最常见的,甚至直接体现在CPU的设计中。这种思维定势一直印象着我们,以至于在面对异步中的问题时,经常显得无从为力,捉襟现肘。

在异步开发中,最重要的是控制,我们一直强调程序员要对他的程序有控制力。我们要从源头,从程序模块设计的时候,就要分析可能的情况,给出有效的解决方案,并把这种控制力一直持续到开发实现,测试验证的过程中。这样,我们才不会因为一个微小的疏漏而搭上整个测试、开发团队一个周末的休息时间。

现实情况中,异步实现的多样性不可避免。因为开发人员的习惯,或者只是非常偶然的因素,在异步的实现方式上会出现很多的变化,这些变化有时候是很微小的,不仔细分析都很难说出两种实现到底有什么区别,然而对整个逻辑的影响却很大。这时候,我们不得不限制开发过程中的发散思维,以一些成文或者不成文的规范要求自己。

与很多开发规范一样,异步规范是用来约束开发行为的,以达到团队成员之间协调一致。具体来说,这些约束主要针对异步开发中,异步功能的”实现者“与”使用者“之间的调用方式,以及对接口语义的理解。

在讨论具体的规范之前,我们不妨先看看异步规范是如何制定的。实际上,规范并不是凭空而来的,它是在一定场合中,为了解决一类问题而制定的。因此,异步规范并不是只有一套,在不同的应用场合有着相适应的不同的规范。

异步规范主要分两个部分:异步调用的规范,异步回调的规范。这个不难理解,因为这正是异步工作方式的体现。每个部分又分为两个小部分,分别对异步”实现者“与”使用者“做出约定。但是,有一个特别需要注意的地方,就是异步取消的行为规范。

虽然没有在文档中特别强调,但是 boost asio 中对异步IO 有着一套严格的全局一致的规范,这也是 boost asio 有如此强大生命力的原因之一。因为有规范即意味着可控性,这在软件工程中是很重要的要求。

我们就以两大部分,四个小部分的方式,简单描述一下 boost asio 的异步规范:

  • 异步调用
    • 调用各个接口没有特殊限定,可以在回调中调用下一个异步,可以多线程调用
    • 不要期望一定能够取消异步,即使在回调被调用之前执行取消
    • 关闭 IO 对象,会取消该对象的异步操作
    • 删除(析构) IO 对象,会 close 该对象
  • 异步被调用
    • 需要实现各个接口的线程安全
    • 不能抛出异常
    • 取消可以失败
  • 回调调用
    • 不在异步请求的调用栈中执行异步回调
    • 不需要考虑调用回调时的线程安全性
    • 需要考虑回调接口抛出异常
  • 回调被调用
    • 需要考虑回调接口的线程安全性
    • 可以抛出异常
    • 取消异步操作时,异步回调不能被取消

在多线程场合,boost asio 这样描述:

In general, it is safe to make concurrent use of distinct objects, but unsafe to make concurrent use of a single object. However, types such asio_service provide a stronger guarantee that it is safe to use a single object concurrently.

通常的(意思是:对于线程安全性, boost asio 并没有什么特别的约定),在不同的对象上多线程并发请求是安全的,但是在同一个对象上的多线程并发请求不安全。(这就是“通常”的意思,因为不做特别处理的对象,就是这样)。然而,像 io_service 这样的对象是多线程并发安全的。

但是,联想到 boost asio 的 IO 对象内部保存着共享的服务单实例的 c++ 引用,那么第一条约定:在不同对象上的并发安全,其实是需要服务实现其并发安全性。

Multiple threads may call io_service::run() to set up a pool of threads from which completion handlers may be invoked. This approach may also be used with io_service::post() to use a means to perform any computational tasks across a thread pool.

多个线程可以调用 io_service::run() 来建立一个线程池,回调函数由这些线程来执行。这个机制可以被用在 io_service::post() 上,用来在线程池中执行某个计算任务。

换个说法就是:回调函数到底需要不需要并发安全,是异步使用者说了算,只用一个线程调用 io_service::run() 的时候,异步回调不需要考虑并发安全,除非在使用者方面还有其他线程与异步回调并发访问数据。

总的来说,boost asio 异步的使用者需要关注并发安全。这对异步功能的”提供者“来说,是一个好消息,他可以专注于异步的功能实现了。但是,作为异步”使用者“,也没有必要悲观,事情不是想象中的那么复杂,对于异步中的多线程并发,我们有着一套完成的方法学来应对它,boost asio 也提供了很多的工具类来帮助我们处理线程并发安全问题。

仅就规范而且,boost asio 在线程方面约定很简单,在后面的章节中,我们还会穿插线程并发方面的内容,现在我们回到前面的几条规范,有必要做一下进一步的解释。

首先,第一条:回调是异步的,不会在异步请求的调用栈中执行异步回调。

在某些时候,异步操作很快完成,(比如,检测到存在错误状态,不能执行该操作),这时候,一种未加思索的做法是直接调用回调函数。

 

这种做法,违背了 boost asio 规范,在调用栈中执行了异步回调。然而这有什么问题呢?现在我们不好回答,因为这与使用者如何使用有关。

一种情况,是程序死锁,

堆栈溢出

程序行为异常

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Fighting Horse

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值