|
From: | Jonathan Larmour |
Subject: | Re: [lwip-users] SemSignal gets called on a already signaled semaphore |
Date: | Fri, 01 Jun 2007 12:17:00 +0100 |
User-agent: | Mozilla Thunderbird 1.0.8-1.1.fc3.4.legacy (X11/20060515) |
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 mutexJonathan,As a clarification of the above example, is the intention for the mutex used by the semaphore pend to be the same as the oneused by thesemaphore post? I imagine not, otherwise the pend would wait on the condition variable with the mutex locked, thereforepreventing a postfrom 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
[Prev in Thread] | Current Thread | [Next in Thread] |