Contiki的内核分析-协程机制(一)

本文深入探讨Contiki的process-event模型中的process(协程)机制。协程在Contiki中表现为一种轻量级线程(protothread),通过非抢占式调度,使用2个字节保存状态。文章分析了协程的逻辑层面,包括如何启动、放弃和获取CPU,以及协程的结束过程。此外,还介绍了Contiki中协程如何通过事件驱动机制被动获取CPU的细节。
摘要由CSDN通过智能技术生成

导读

本文通过分析Contiki的源码,梳理Contiki的process-event模型中的process机制。

通过前文的阐述我们贯通了event机制的原理。从本文开始,分析Contiki的process机制。

综述

Contiki的process机制实质上是一种协程调度机制,区别于抢占式调度,它只使用了2个字节的变量保存了process的“栈环境[1]”。所有的process以链表的形式保存。官方对此的称呼是protothread,即轻量级线程。但是协程是对它更好的诠释。在协程的环境下,每个process被动的获得cpu执行权,主动的放弃cpu执行权。因此在编程时务必要小心,防止产生死循环,导致整个系统宕机。

为了完全贯通Contiki中的协程机制,我们需要分为2个方面去阐述它:协程逻辑和协程实现,本篇主要阐述协程的逻辑层面,下篇阐述协程的语法实现层面。

协程运行的预备工作

在旅程的最开始,我们先来看一看Contiki的协程----process的类型定义。删除了一些无关紧要的部分,使代码更简洁。

#define PT_THREAD(name_args) char name_args
struct process {
   
  //链接域
  struct process *next;
  //和process绑定的函数指针
  PT_THREAD((* thread)(struct pt *, process_event_t, process_data_t));
  //保存了行数
  struct pt pt;
  //process状态和poll请求
  unsigned char state, needspoll;
};

删去了边边角角的process的类型定义简洁明了,甚至不需要额外解释。

为了使Contiki的process真正的运作起来,我们需要先执行process_init和process_start[2]函数,使etimer_process开始发挥作用。下面我们剖析这2个函数。

void
process_init(void)
{
   
  lastevent = PROCESS_EVENT_MAX;
  nevents = fevent = 0;
  process_current = process_list = NULL;
}

同样的删去了无关紧要的部分使代码更简洁。这里可以看到Contiki的最小未使用事件被置为了PROCESS_EVENT_MAX,归0了event循环队列的首尾指针[3],归0了当前运行的process和process链表。一段很简单的初始化函数。接下来的process_start才是重点。

void
process_start(struct process *p, process_data_t dataa)
{
   
  struct process *q;

  /* First make sure that we don't try to start a process that is
     already running. */
  for(q = process_list; q 
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值