异步代码的代价及状态变量竞争问题

先考虑一个问题：如果任务引入延迟，为什么使用它们？为什么不一直使用异步代码？原因很简单：竞争，尤其是数据竞争。执行优先级的基本问题是它能修改当前运算的状态，这可能导致系统进入不稳定的状态。

例4.3：toggle命令，它翻转状态比特并返回该值

现在来看这个执行，从state=0开始：

在这个执行中，当第一个toggle返回，调用组件认为state=1。但最后在中断后state=0。

如果允许对单个语句执行中断，这个问题更为严重。例如，在Micaz或者Telos节点上，读或写32位的数字需要多个指令。当在两个指令之间中断语句时，这样所读到的数据一部分是新值，而另一部分是旧值。(www.xing528.com)

数据竞争中最突出的问题是状态变量问题。举个例子，设想AMStandard中的一小段代码，在这里状态变量指示组件是否忙。

例4.4：

如果这个命令是异步的，在条件if（！state）和state=TRUE间可能插入另一个组件，同样试图发送数据分组。第二个调用会看到state是FALSE，然后会设定state为TRUE，并开始发送数据，返回SUCCESS。但第一个调用者的结果会使state再次设定为TRUE，同时开始发送数据，返回SUCCESS。这两个数据包中只有一个能发送成功，除非在调用路径上有额外的错误检测，否则很难发现是哪个出现错误，这可能给调用的组件带来各种各样的错误。为了避免这个问题，发送命令不是异步的。

注意：编程时应尽量使用同步代码。只有当程序代码对运行时机的掌控有较高要求或者应用在对运行时机的掌控有较高要求的场景时，才使用异步代码。