PVFS2 源代码分析之输入输出src/io/job/job-desc-queue任务描述符队列

任务描述符队列（job descriptor queue）是job文件夹下比较简单的模块，但是提供了任务管理的基础结构。

• 数据结构

核心的数据结构是队列中链入的对象——结构体job_desc，定义如下。

struct job_desc{ enum job_type type;/* type of job */ job_id_t job_id;/* job interface identifier */ void *job_user_ptr;/* user pointer */ job_aint status_user_tag; /* user supplied tag */ int completed_flag;/* has the job finished? */ job_context_id context_id; /* context */ struct PINT_thread_mgr_bmi_callback bmi_callback; /* callback information */ struct PINT_thread_mgr_trove_callback trove_callback; /* callback information */ PVFS_hint hints; /* union of information for lower level interfaces */ union { struct bmi_desc bmi; struct trove_desc trove; struct bmi_unexp_desc bmi_unexp; struct flow_desc flow; struct req_sched_desc req_sched; struct dev_unexp_desc dev_unexp; struct null_info_desc null_info; struct precreate_pool_desc precreate_pool; } u; struct qlist_head job_desc_q_link;/* queue link */ struct qlist_head job_time_link;/* queue link */ void* time_bucket;};

job可同时管理BMI、Trove、Flow、Device等多种对象，所以描述符有多种类型，由第3行成员type标识；相应地，第13~23行的联合（union）选取与描述对象对应的结构体，各结构体的具体内容不在此赘述。

 

第4行成员job_id是被描述的任务的唯一ID（句柄），由job注册时通过id-generator获得，请参见相关介绍。

 

第9~10行分别是BMI和Trove的回调函数结构体，两个结构体都是包含一个函数指针，和一个数据指针，后者是前者的参数之一。这些结构体定义在同文件夹下的thread-mgr.h头文件中。

 

第24行是该任务描述符链入队列的节点，队列由quicklist实现，请参见相关介绍。

 

第26行是该任务描述符链入的时间元（time bucket），参见任务时间管理器。该时间元记录着本任务的过期时间和同时结束的其他任务。链入的节点就是第25行的成员job_time_link。

• 功能函数

本模块实现了一个基于quicklist的队列，创建、添加、删除、清空、撤销等操作基本都是对quicklist的操作，阅读代码如有疑问请参见quicklist的介绍。

 

job_desc本身的分配，采用了id-generator的基本注册流程，如函数1。

函数1 alloc_job_desc

struct job_desc *alloc_job_desc(int type){ struct job_desc *jd = NULL; jd = (struct job_desc *) malloc(sizeof(struct job_desc)); // ...... memset(jd, 0, sizeof(struct job_desc)); id_gen_safe_register(&(jd->job_id), jd); jd->type = type; return (jd);};

第6行调用src/common/id-generator/id-generator.c中的函数id_gen_safe_register，获得新建任务描述符jd的整型句柄（第一个输出参数），通过该句柄可以获得相应的任务描述符。【注意】这个句柄同时作为对应任务的ID，存储在任务描述符的job_id成员。

 

函数id_gen_safe_register将上述从任务ID到任务描述符的映射，存储在同文件id-generator.c中声明的quickhash类型全局变量s_id_gen_safe_table中，我们在介绍状态机生命周期时已有提及。

 

• 组件应用

任务描述符队列主要应用在job中。在job.c文件中定义了三类队列：

static job_desc_q_p completion_queue_array[JOB_MAX_CONTEXTS] = {NULL};static job_desc_q_p bmi_unexp_queue = NULL;static int bmi_unexp_pending_count = 0;static job_desc_q_p dev_unexp_queue = NULL;static int dev_unexp_pending_count = 0;

第1行是一组队列，存储各个上下文（context）中完成任务的描述符队列。

第3~4行是意外网络消息相关任务的描述符队列。

第5~6行是意外设备消息相关任务的描述符队列。

 

完成任务描述符队列（completion queue）是在任务开辟上下文时创建的，如函数2。

函数2 job_open_context

int job_open_context(job_context_id* context_id){ int context_index; /* find an unused context id */ gen_mutex_lock(&completion_mutex); for(context_index = 0; context_index < JOB_MAX_CONTEXTS; context_index++) { if(completion_queue_array[context_index] == NULL) { break; } } if(context_index >= JOB_MAX_CONTEXTS) { /* we don't have any more available! */ gen_mutex_unlock(&completion_mutex); return(-EBUSY); } /* create a new completion queue for the context */ completion_queue_array[context_index] = job_desc_q_new(); // ...... gen_mutex_unlock(&completion_mutex); *context_id = context_index; return(0);}

完成任务描述符队列存储在一个预先开辟好的数组中，数组长度是JOB_MAX_CONTEXTS，顾名思义即上下文数目的上限值。第6~12行按下标由小到大遍历数组，发现可以插入队列的位置就中止。而后第20行创建相应的完成任务描述符队列并存储在该位置，其下标值作为新建上下文的ID，通过输出参数返回（第23行）。由此可见，开辟上下文也就是意味着创建相应的完成任务描述符队列。

 

意外网络消息任务描述符队列bmi_unexp_mutex和意外设备消息任务描述符队列dev_unexp_mutex则是在setup_queues函数中统一创建的，该函数在任务初始化函数job_initialize中被调用。

函数3 setup_queues

static int setup_queues(void){ gen_mutex_lock(&bmi_unexp_mutex); bmi_unexp_queue = job_desc_q_new(); gen_mutex_unlock(&bmi_unexp_mutex); gen_mutex_lock(&dev_unexp_mutex); dev_unexp_queue = job_desc_q_new(); gen_mutex_unlock(&dev_unexp_mutex); if (!bmi_unexp_queue || !dev_unexp_queue) { /* cleanup any that were initialized */ teardown_queues(); return (-ENOMEM); } return (0);}

注意创建队列时需要加锁。相应的销毁函数是teardown_queues，不再赘述。