cxenophontos at hammers.com
Wed Mar 21 20:45:21 UTC 2007
An update to the problem:
After running 22 hours, there were two instances of the failure. No
apparent change from using RTEMS_COUNTING_SEMAPHORE - unless other
attributes conflict with using a counting semaphore(?), ie.,
RTEMS_NO_INHERIT_PRIORITY, RTEMS_NO_PRIORITY_CEILING, etc.
I'm in the process of rebuilding the application with RTEMS4.6.6, and will
try that once we work out some cygwin/build issues.
In the meantime, for the next test, I'm going to restore original semaphore
attributes, then - disable/enable that interrupt upon task entry/exit. This
should prevent the "walking" of the semaphore release while the task is
From: Eric Norum [mailto:norume at aps.anl.gov]
Sent: Wednesday, March 21, 2007 3:22 PM
To: Sergei Organov
Cc: rtems-users at rtems.com; Chris Xenophontos
Subject: Re: rtems_semaphore_obtain
On Mar 21, 2007, at 2:13 PM, Sergei Organov wrote:
> As for changing current semantics of RTEMS_SIMPLE_BINARY_SEMAPHORE,
> afraid some existing code might be affected, and adding yet another
> different kind of "semaphore" may add to already existing confusion.
I don't think that you would be changing the semantics (other than
fixing a possible bug) -- how many ways are there for a simple binary
semaphore to operate?
> Anyway, if decision will be to add true binary semaphores support
> to the
> RTEMS API, I'll be happy to provide a patch. [Note that RTEMS kernel
> does have the support].
I vote yes.
Any comments from the rest of you folks out there?
Eric Norum <norume at aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
More information about the users