多对一网守任务同步

Question

我正在开发一种使用网守任务来访问共享资源的设计.我现在的基本设计是网守任务正在接收的单个队列以及将请求放入其中的多个任务.

这是一个内存有限的系统,我正在使用FreeRTOS(Cortex M3端口).

问题如下:异步处理这些请求非常简单.请求任务将其请求排队并进行业务,轮询,处理或等待其他事件.为了同步处理这些请求,我需要一种机制让请求任务阻塞,这样一旦处理了请求,网守就可以唤醒调用该请求的任务.

我能想到的最简单的设计是在每个请求中包含一个信号量,但考虑到内存限制和FreeRTOS中信号量的相当大的大小,这是不切实际的.

我想到的是使用任务挂起和任务恢复功能来手动阻止任务,将句柄传递给网守,当请求完成时,它可以恢复任务.暂停/恢复有一些问题,我真的想避免它们.单个恢复调用将唤醒任务,无论其被多少次被其他调用暂停,这可能会产生不良行为.

一些简单的伪C来演示suspend/resume方法.

void gatekeeper_blocking_request(void)
{
     put_request_in_queue(request);
     task_suspend(this_task);
}

void gatekeeper_request_complete_callback(request)
{
     task_resume(request->task);
}

我计划在此期间使用的解决方法是使用异步调用并在每个请求任务中完全实现阻塞.当操作完成时,网守将执行提供的回调,然后可以发布到任务的主队列或特定信号量,或任何需要的信号.对请求进行阻塞调用本质上是一个便利功能,因此每个请求任务都不需要实现此功能.

Pseudo-C用于演示特定于任务的阻塞,但这需要在每个任务中实现.

void requesting_task(void)
{
     while(1)
     {
         gatekeeper_async_request(callback);
         pend_on_sempahore(sem);
     }
}

void callback(request)
{
     post_to_semaphore(sem);
}

也许最好的解决方案就是不在网守和API中实现阻塞,并强制每个任务来处理它.但是,这将增加每个任务流程的复杂性,我希望我能避免它.在大多数情况下,所有调用都将阻止,直到操作完成.

是否有一些我缺少的构造,或者甚至只是一个更好的术语来解决这类问题？在我的搜索中,我没有遇到过这样的事情.

附加说明 - 网守任务的两个原因:

1. 需要大堆栈空间.网守可以拥有一个只需要所有内存的堆栈,而不是将这个要求添加到每个任务中.

2. 资源并不总是可以在CPU中访问.它不仅可以同步CPU中的任务,还可以同步CPU外部的任务.

Answer 1

使用互斥体并使看门人成为子例程而不是任务。