Get state binary semaphore

[Nick Withers]

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.
-- 
Nick Withers

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