mr68360 wrote on Monday, May 16, 2011:
Nice, mizer. I assume that your suspend is actually a pend on the semaphore you created (init waits for the dependent task to signal that it-the dependent task-is ready to allow more init to occur)?
One might wish to provide an upper-bound time limit on that pend, given that the dependent task might not itself finish its own initialization in a timely manner.
On the other hand, if one doesn’t care about start-up order, one could create a unique semaphore for each non-init task (let’s call them ‘child tasks’). These semaphores begin life in the non-signaled state. When the init task spawns each child, it simply waits on all of the semaphores-waiting for each child to signal that its initial operations are complete. The order of wait would not be critical: regardless of signaling order, the init task would only fall through when it can take all the semaphores it is waiting on.
(An example of what I mean: child 1 is spawned, then child 2, but child 2 signals before child 1 does. If init waits first for child 1, then fine-it waits. After init takes child 1’s semaphore, it immediately takes child 2’s semaphore-because it had previously been signaled. Regardless of the order, eventually everyone’s semaphore get’s taken.)
But, again, some upper time limit for waiting on each child might be in order.
I like mizer’s idea because only one semaphore is involved (less resources), and it lends itself to fine-grained start-up control. However, if the start-up sequence changes, there there must be code rearrangement. If the order is less important than not having to modify code-that is, if one simply wants to provide a more coarse-grained, “bulk” approach, perhaps my scheme would serve.
I love lots of tools for lots of different problems!