rtems_semaphore_obtain

[Chris Xenophontos]

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
pending.  

thanks
Chris Xenophontos


-----Original Message-----
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,  
> I'm
> 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
(630) 252-4793