Re: [lwip-users] SemSignal gets called on a already signaled semaphore

[Jonathan Larmour]

Goldschmidt Simon wrote:
> > > > So waiting on a semaphore would mean:
> > > > lock mutex
> > > > while (count==0)
> > > >  wait on condition variable
> > > > count--
> > > > unlock mutex
> > > >
> > > > And posting a semaphore:
> > > > lock mutex
> > > > count++
> > > > signal condition variable
> > > > unlock mutex
> > >
> > >
> > > Jonathan,
> > >
> > > As a clarification of the above example, is the intention for the 
> > > mutex used by the semaphore pend to be the same as the one 
> >
> > used by the 
> >
> > > semaphore post? I imagine not, otherwise the pend would wait on the 
> > > condition variable with the mutex locked, therefore 
> >
> > preventing a post 
> >
> > > from occurring...
> >
> > It is the same mutex. Condition variables always have a mutex 
> > associated with them. When you wait on a CV, the mutex is 
> > automatically unlocked by the OS, and when you wake up after 
> > the CV is signalled, the OS automatically relocks the mutex 
> > before the wait function returns.
>
>
> Reading that explanation I'm afraid the OSes I use don't have such
> condition variables! So making them mandatory for lwIP seems not
> such a portable idea to me...

Really? I'm amazed if so. Any OSes I should have heard of, or homegrown? I 
am sort of assuming that if someone can write a homegrown OS they can 
implement mutexes/condition variables for it if they need to.

In any case, I think you can implement mutexes/condition variables in 
terms of semaphores if you also have a unique way to identify a thread. 
Obviously you wouldn't be able to implement any method of preventing 
priority inversion, but that's no worse than at present.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine