gedare at gwmail.gwu.edu
Tue Nov 2 17:25:09 UTC 2010
On Tue, Nov 2, 2010 at 11:41 AM, Leon Pollak <leonp at plris.com> wrote:
> On Tuesday November 2 2010, Joel Sherrill wrote:
>> On 11/02/2010 09:42 AM, Leon Pollak wrote:
>> > Hello, all.
>> > Using barrier, I have the following problem:
>> > The main task releasing the barrier when everybody have started and ready
>> > to work does not know the exact number of tasks to be started (and
>> > initialize the HW). This is because there is a configuration file, which
>> > decides which tasks to start, one by one.
>> > Releasing barrier manually also is not the best approach, as the main
>> > task does not know how much time does it take for each task to
>> > initialize its HW and be ready to start.
>> > So, the best solution for me would be the ability to "correct" the update
>> > the maximum_waiters parameter in the barrier_create call.
>> > But how can this be done?
>> Add a new directive? and supporting core service?
>> FWIW we are available for small tasks like this.
> I think - no. Just a check in "create" call that the existing barrier is
> "recreated" with the new value...:-)
Who will set the new value? When are valid changes to the 'new'
waiting count available? If you want this done "cleanly" then you will
need to implement both an rtems_XXX and a score service, since the
barrier is accessed via the rtems_XXX interface but implemented at the
CORE level. Care must be taken to make sure that changing the max
count triggers a check of the number of waiters, to avoid deadlock in
case max is reduced below the number of current waiters.
For a 'roll your own' solution, you might be able to implement a
barrier at the user level using a 'barrier' semaphore/mutex that is
initially locked. After each task finishes its initialization, have
it block on the 'barrier' semaphore. To release the barrier, have your
main task call semaphore_flush followed by semaphore_release on the
'barrier' semaphore. (Note: You need to release the semaphore after
flushing it.) This will give you control over the release condition of
the barrier as well. You might add a loop in your main task that
checks on a shared variable that provides the maximum count of waiters
and the current count waiting (protecting these with a separate mutex
of course). When current >= max, call semaphore_flush followed by
semaphore_release on the 'barrier' semaphore (and release the mutex).
Otherwise have your main task yield or sleep for a tick -- depending
on your timing constraints at init time.
This would avoid the problem of not knowing the timing. All you will
need to do is set the initial value of max to some pre-determined
possible max, and then update max based on the configuration settings.
> rtems-users mailing list
> rtems-users at rtems.org
More information about the users