应用定义调度ADS

Descritpion 描述

Application-defined scheduling (ADS for short) is an application program interface (API) that enables applications to use application-defined scheduling algorithms in a way compatible with the scheduling model defined in POSIX. Several application-defined schedulers, implemented as special user threads, can coexist in the system in a predictable way.

应用程序定义的调度（简称ADS）是一种应用程序接口（API），使应用程序能使用ADS的调度算法，这类使用要兼容POSIX中定义的调度模型。几个以特殊用户线程实现的应用程序定义调度器,可以以预测方式在系统中共存。

Although research in scheduling theory has been one of the most active and fertile areas in real-time, most of the results had never been implemented in commercial RTOS. 虽然调度理论的研究一直在最活跃，实时收获也很大，大部分结果从未在商用RTOS实施。

The application defined scheduler in RTLinux is a key facility which will help in the adoption of the already available scheduling theory. The ADS enabled RTLinux to implement, in a very portable way, new scheduling algorithms that can be ported immediately to other RTOS.

在RTLinux的应用程序中定义调度是一个关键的设施，将应用已有的调度理论，这样接受到了帮助。ADS使RTLinux实现了，以一个非常便携的方式，新的调度算法，这个算法可立即移植到另一个RTOS。

API / Compatibility API /兼容性

The application defined scheduler facility API is a little more complex than "normal" operating systems services like file management since the ADS has to provide two different API’s. One API for the application scheduler thread and another API for the application scheduled thread.

应用程序定义调度器的API是一个比文件管理这类“正常”的操作系统服务更复杂，ADS必须提供两个不同的API。一个API对应应用程序调度程序线程,另一个API的对应被调度程序的线程。

Following is the list of function that can use the application scheduler: 下面是可以使用应用程序调度程序的功能列表：

/* program scheduling actions ( suspending or activating threads) */
int posix_appsched_actions_addactivate(posix_appsched_actions_t *sched_actions,
pthread_t thread);
int posix_appsched_actions_addsuspend (posix_appsched_actions_t *sched_actions,
pthread_t thread);
int posix_appsched_actions_addlock (posix_appsched_actions_t *sched_actions,
pthread_t thread, const pthread_mutex_t *mutex);
/* Execute Scheduling Actions */
int posix_appsched_execute_actions (const posix_appsched_actions_t *sched_actions,
const sigset_t *set,
const struct timespec *timeout,
struct timespec *current_time,
struct posix_appsched_event *event);
/* Getting and setting app. Scheduled thread’s data */
int pthread_remote_setspecific(pthread_key_t key,pthread_t th,void *value);
void *pthread_remote_getspecific(pthread_key_t key,pthread_t th)
/* Set and get mutex-specific data */
int posix_appsched_mutex_setspecific (pthread_mutex_t *mutex,void *value );
int posix_appsched_mutex_getspecific (const pthread_mutex_t *mutex, void **data);
/* Scheduling events sets manipulation */
int posix_appsched_emptyset (posix_appsched_eventset_t *set);
int posix_appsched_fillset (posix_appsched_eventset_t *set);
int posix_appsched_addset (posix_appsched_eventset_t *set, int appsched_event);
int posix_appsched_delset (posix_appsched_eventset_t *set, int appsched_event);
int posix_appsched_ismember (const posix_appsched_eventset_t *set, int appsched_event);
int posix_appschedattr_seteventmask (const posix_appsched_eventset_t *set);
int posix_appschedattr_geteventmask (posix_appsched_eventset_t *set);

While in the application scheduled thread’s side the API is: 而在被应用程序调度线程的API是:

/* Explicit Scheduler Invocation */
int posix_appsched_invoke_scheduler (void * msg, size_t msg_size);
/* Manipulate application scheduled threads attributes */
int pthread_attr_setthread_type(pthread_attr_t *attr, int type);
int pthread_attr_setappscheduler(pthread_attr_t *attr, pthread_t sched);
int pthread_attr_setappsched_param(pthread_attr_t *attr, void *param, int size);
int pthread_attr_getappscheduler(pthread_attr_t *attr, pthread_t *sched);
int pthread_getappsched_param(pthread_t thread, void *param,int *size);
/* Application-defined Mutex Protocol */
int pthread_mutexattr_setappscheduler (pthread_mutexattr_t *attr,
struct rtl_thread_struct * appscheduler);
int pthread_mutexattr_getappscheduler (const pthread_mutexattr_t *attr,
struct rtl_thread_struct * *appscheduler)
int pthread_mutexattr_setappschedparam (pthread_mutexattr_t *attr, const
struct pthread_mutex_schedparam *sched_param);
int pthread_mutexattr_getappschedparam (const pthread_mutexattr_t *attr,
struct pthread_mutex_schedparam *sched_param);
int pthread_mutex_setappschedparam (pthread_mutex_t *mutex, const
struct pthread_mutex_schedparam *sched_param);
int pthread_mutex_getappschedparam (const pthread_mutex_t *mutex,
struct pthread_mutex_schedparam *sched_param);

Implementation issues 实现问题

Due to the special characteristic of RTLinux, where all the threads as well as the RTLinux executive share the same memory space, system calls are implemented as simple functions calls. Even in some cases, the API is implemented as inline functions, and data can be shared (not copied) between RTLinux and user threads. It is important to note that these optimisations do not jeopardise the standard API.

由于RTLinux的特殊特性，其中所有的线程以及RTLinux的执行共享相同的存储器空间。系统调用来实现简单函数的调用。甚至在某些情况下,API是作为内联实现函数并且数据可以在RTLinux(不是复制)和用户线程之间共享。要注意的是，这些优化不危及API的标准。

In the initial proposal of the POSIX-Compatible Application-defined Scheduling some changes to the sched_param structure were proposed. Changing this structure will require the modification, among other things, of the standard "C" library. The new version of the "C" library will not be backward compatible. Therefore, we decided not to modify the sched_param structure with new member variables but add new functions to the API to send that parameters to the kernel.

在POSIX-Compatible应用程序定义的调度的初步建议中提出了一些改变sched_param结构。改变这个结构需要改变修改的除了其他的之外还有标准的“C”库。新版本的“C”库不会向后兼容的。因此,我们决定不修改sched_param结构的新成员变量，但添加新的API功能来发送内核参数。

Validation criteria 验证标准

The main problem of POSIX-Compatible application defined scheduling is the overhead introduced. This overhead can be divided in two parts:

POSIX的兼容应用程序定义调度的主要问题是引入的开销。这个开销可以分为两个部分:

Application scheduled thread overhead: There is no significative difference between the overhead introduced when scheduling a system scheduled thread or an application scheduled thread.

应用调度线程的开销：在调度系统、调度线程或应用调度线程时引入的开销之间没有显著差异。。

Application-defined scheduler thread overhead: This thread will introduce at least an additional switch context per application scheduled thread activation (deppending on the scheduling policy) plus the cost of implementing the scheduling policy (find the most urgent, arm timers,....). In the case of the fixed priority preemptive scheduler (the RTLinux default scheduling policy) the overhead introduced is three times the overhead needed to schedule a system thread per scheduled thread activation (introduces two context switches per scheduled thread plus the cost of implementing the policy).

应用程序定义的调度程序线程开销：这个线程将引入至少一个额外的上下文切换，对应每被调度应用线程激活（依赖调度策略)，还要考虑实现调度策略的成本(找到最紧迫,用计时器,....)。在的固定优先级抢占式调度程序(RTLinux默认调度政策)引入的开销是三次安排所需的开销，系统线程每调度线程激活(引入了两个上下文切换将线程+实现政策的成本)。

友情链接

汕头招聘网 | 山东招聘网 | 郑州教育培训 | 软件下载