Starting 'N' Tasks with a counting sem...

Kernel
1

steveb75 wrote on Thursday, November 25, 2010:

Hello All.

(Using PIC32 Starter Kit)

I’m trying to implement a sync/task start mechanism using counting semaphores.  The purpose is to
ensure all task Q’s/Semaphores and H/W is configured before any task begins communicating with
another task.

I have 5 tasks, each creating a Q or semaphore and corresponding H/W configuration.  Each task calls
semGive on a counting (taskReady) semaphore then immediately blocks on another counting (taskStart)
semaphore.
I have a 6th  ‘supervisor’ task that blocks on the taskReady semaphore and loops (semTake) around this
semaphore until all tasks have reported ready.  Once all tasks have given the taskReady semaphore, the
‘supervisor’ task then gives the taskStart semaphore 5 times to allow each task to continue.

The problem I’m facing is only the following two tasks that are created after the supervisor task (from within main())
ever start i.e. supervisor is created 1st followed by task A, task B etc…. These tasks, A and B call semGive(taskReady) and the supervisor task unblocks twice (semTake(taskReady).  A breakpoint in the third created task (or any of the other tasks) never hits?

My understanding is that each task should start in accordance with the scheduler rules i.e based on the task pri or maybe the task creation order.  After the supervisor task is unblocked twice for task A/B’s semGive(taskReady), it becomes blocked again (permantently).  I would expect one of the other tasks to run and call its semGive(taskReady)?

Any suggestions/advice would be greatly appreciated.

Regards,
Steve

2

davedoors wrote on Thursday, November 25, 2010:

It sounds like a very complex scheme and suspect the problem lies in its complexity somewhere.

Why not initialize the hardware before starting the scheduler? If you want to modularize the drivers you can still have the driver encapsulate an initialization function that is called before the task is started.

Alternatively you could have the tasks suspend themselves when they are ready and then the main task can simply check that all the tasks are suspended before starting the real work.

3

richard_damon wrote on Thursday, November 25, 2010:

One though, have you checked that the tasks were successfully created? If you run out of heap, then the tasks won’t all be created.

4

steveb75 wrote on Thursday, November 25, 2010:

Thx chaps for the prompt feedback!

It seems I should not have been lazy and checked if each task was created correctly.  Turns out more memory is required.  Good call Richard.

Dave - thx for your suggestion as well.

Cheers,
Steve