Question

I’m working on a design that uses a gatekeeper task to access a shared resource. The basic design I have right now is a single queue that the gatekeeper task is receiving from and multiple tasks putting requests into it.

This is a memory limited system, and I’m using FreeRTOS (Cortex M3 port).

The problem is as follows: To handle these requests asynchronously is fairly simple. The requesting task queues its request and goes about its business, polling, processing, or waiting for other events. To handle these requests synchronously, I need a mechanism for the requesting task to block on such that once the request has been handled, the gatekeeper can wake up the task that called that request.

The easiest design I can think of would be to include a semaphore in each request, but given the memory limitations and the rather large size of a semaphore in FreeRTOS, this isn’t practical.

What I’ve come up with is using the task suspend and task resume feature to manually block the task, passing a handle to the gatekeeper with which it can resume the task when the request is completed. There are some issues with suspend/resume, though, and I’d really like to avoid them. A single resume call will wake up a task no matter how many times it has been suspended by other calls and this can create an undesired behavior.

Some simple pseudo-C to demonstrate the suspend/resume method.

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

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

A workaround that I plan to use in the meantime is to use the asynchronous calls and implement the blocking entirely in each requesting task. The gatekeeper will execute a supplied callback when the operation completes, and that can then post to the task’s main queue or a specific semaphore, or whatever is needed. Having the blocking calls for requests is essentially a convenience feature so each requesting task doesn’t need to implement this.

Pseudo-C to demonstrate the task-specific blocking, but this needs to be implemented in each task.

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

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

Maybe the best solution is just to not implement blocking in the gatekeeper and API, and force each task to handle it. That will increase the complexity of each task’s flow, though, and I was hoping I could avoid it. For the most part, all calls will want to block until the operation is finished.

Is there some construct that I’m missing, or even just a better term for this type of problem that I can google? I haven’t come across anything like this in my searches.

Additional remarks – Two reasons for the gatekeeper task:

1. Large stack space required. Rather than adding this requirement to each task, the gatekeeper can have a single stack with all the memory required.

2. The resource is not always accessible in the CPU. It is synchronizing not only tasks in the CPU, but tasks outside the CPU as well.

Answer 1

Use a mutex and make the gatekeeper a subroutine instead of a task.