Get state binary semaphore

[Nick Withers]

On Tue, 2015-07-14 at 15:08 +1000, Nick Withers wrote:
> On Mon, 2015-07-13 at 12:37 +0300, Suprunenko Evgeniy wrote:
> > Hello. 
> > 
> > > >> I am trying to get state of my binary semaphore. I need state,
> > > >because I release semaphore at my interrupt handler (If semaphore
> > > >didn't obtained, I must print error).
> > > >> I found similar sample in testsuites (sptests/spincritical06).
> > > >
> > > >I'm not sure I'm understanding your scenario.
> > > >
> > > >You say you release the semaphore in the interrupt handler (which is
> > > >fine) then if the semaphore isn't obtained you must error... What's
> > > >obtaining the semaphore? A user task, right? So error there if there's
> > > >some reason the semaphore obtain fails?
> > > >
> > 
> > if the semaphore isn't obtained, I don't get error, because in code:
> > 
> > CORE_mutex_Status _CORE_mutex_Surrender(...)
> > {
> >   /* XXX already unlocked -- not right status */
> > 
> >   if ( !the_mutex->nest_count )
> >     return CORE_MUTEX_STATUS_SUCCESSFUL;
> > 
> >   the_mutex->nest_count--;
> > ....
> > 
> > }
> > 
> > I see, that function returns SUCCESSFUL at all variants.
> 
> That's the code for *releasing* it, not for obtaining it. The note
> "already unlocked -- not right status" I suspect is because arguably it
> should return a status that says "hey - you should never have called me,
> I'm not locked!" [1].
> 
> > > >But it shouldn't be possible for it to fail... It should either block
> > > >because the interrupt hasn't happened or succeed and return because it
> > > >has.
> > > >
> > > >Is it that you want to error if the interrupt happens again without
> > > >the user-space task having handled it? If so, I'd say that's a bad
> > > >idea in general, because you simply can't guarantee that the user-
> > > >space task will run between two interrupts.
> > > >
> > > >Can you design things such that the interrupt source is not reenabled
> > > >until the user-space task has been woken and done its thing? Yes, you
> > > >may miss interrupts. The alternative is that you may never be *not*
> > > >servicing the interrupt.
> > 
> > My device waits for new packets from UART. Some packets is not for my device.
> > If receiving packet is not waiting, my user task doesn't must to get it.
> 
> So don't release the semaphore to release the user task if it's not the
> right target?
> 
> I may well be missing something obvious, sorry if that's the case!
> 
> [1] Though I wouldn't necessarily agree; I'd argue that releasing a
> semaphore (for the general definition of a semaphore, not necessarily a
> particular implementatin that provides stronger guarantees) that was
> never obtained is undefined behaviour... It's my responsibility to
> ensure I don't violate that contract.

That's not quite right, sorry... How about "For a *binary* semaphore,
attempting to increment the resource count above 1 makes no sense".

It might be nice if _CORE_mutex_Surrender() let you know that you'd
tried it (and hence the comment in the code), but then what? As you say,
print an error (which isn't typically something you want to do from an
interrupt handler)... but then? Your design should ensure it can't
happen.

I don't know how much help I or others can be without knowing more about
how it all ties together (e.g., how's your interrupt handler invoked? I
personally also don't know anything about the UART driver(s)), but I
think I can say that your problem isn't with RTEMS as such and that
getting the state isn't the right approach.
-- 
Nick Withers

Embedded Systems Programmer
Department of Nuclear Physics, Research School of Physics and Engineering
The Australian National University (CRICOS: 00120C)