This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FW: binary semaphores from counting or mutex


Aaron,

> This is a single processor system, EP7312.
May be I didn't understand something, but I don't get how "4 threads could hit
the same sempahore at nearly the same time" on single processor, as you had
mentioned earlier.

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

Assuming your test case is like what Nick posted and nothing improper is being
done in your application/test-code, and considering  the fact
> If I add in thread delays to stagger execution of the four threads, then all
> threads run beautifully and predictably.

may be you are ending up with either so far unknown code-generation and/or
hardware bug.
Your adding of thread delays (for that matter, even a single nop instruction)
will changes the code flow and is quite likely to hide the bug, giving the
impression that adding delay is something sacred.

> This seemingly inane test always ends by "locking the keys in the car."  The
> semaphore count gets set to zero and all threads are waiting on after only
> executing the one thread once.
Hope you have ensured that mentioned is happening by examining the appropriate
memory dump --
- if semaphore count member variable's value  is 0
- if all the threads involved with this semaphore on semaphore's wait queue
- what makes you decide if threads have been executed just once? do you have
some sort of properly initialised counter increments (as in Nick's example code)
that you can examine?

Apart from above checklist, you can also try compiling your eCos and test code
with different optimisation levels (no optimisation, -O1, -O2). If it is code
generation bug, it might get caught.

May be after getting feedback from you on what Nick had asked you, as well as
results of  few investigations as mentioned above, it might help to help get clu
es to your problem. Right now, w/o knowing your code structure and eCos
configuration, whatever clues people here can give are nothing more that
shooting arrows in dark.

In any case, once you find the cause and/or solution of your problem, let list
know about them.

sandeep




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.509 / Virus Database: 306 - Release Date: 8/12/2003


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]