[ECOS] binary semaphores from counting or mutex

[Aaron Case]

eCos Admiralty,

I am porting an application to eCos that was originally written in embedded
OS that used binary semaphores. The C api implements counting semaphores.

As stated in the philosophical tear on the mailing list and evident from API
descriptions in the Massa text, counting semaphores initialized to 1 are
functionally equivalent to binary semaphores.

Another alternative is to use mutexes, or binary semaphores with ownership,
in place of the binary semaphore implementation of the code.

I have noticed that with binary implementation of counting semaphores a race
conditions can occur and cause undefined behavior.  I was able to simulate
an instance whereby 4 threads hit the same semaphore at nearly the same
time, which resulted in undefined behavior. This is however, a worst case
scenario.

So Im faced with a design decision, use counting semaphores configured as
binary(is this safe???), go to mutexs and hope the race condition dosent
occur. Wholesale edits to task synchronization is not an option considering
the thousands of thousands of man hours in the code and the development time
line.

Therefore creating the need for a safe and minimal implementation of either
mutexs or semaphores, which do not require extensive changes to the firmware
synchronization architecture.

Knowing full well that binary semaphores are undoubtedly deprecated by the
eCos community, how safe is the binary implementation of the counting
semaphores? Is it now recommended that binary semaphores be replaced by
mutexs?
Are there any additions to the KAPI that will allow use binary semaphores?

Thanks and Regards,
Aaron Case


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss