Nick Garnett <[EMAIL PROTECTED]> writes: > This patch addresses some issues with the mailbox implementation > raised by the following two threads: > > http://ecos.sourceware.org/ml/ecos-devel/2006-08/msg00004.html > http://ecos.sourceware.org/ml/ecos-discuss/2006-08/msg00170.html > > The first pointed out a possible race condition with CYG_ASSERTCLASS() > if it is called without the scheduler lock claimed. The solution has > been to move all CYG_ASSERTCLASS() calls to places where the scheduler > lock is claimed. > > > The second raised some problems with the use of mailboxes in LWIP. It > is not clear what the issue there was, I cannot see any obvious > problems with the mailbox implementation. However, it did highlight > the fact that the wrong mailbox implementation is being used by > default. > > There are two implementations, a straightforward one (mboxt) that > works the same way as most other eCos synchronization primitives, and > a UITRON-compatible implementation (mboxt2). The main difference is in > the way that a new message is assigned to a waiting thread, and how > multiple threads interact (I won't go into gory details here unless > someone wants me to). > > For some reason the CDL option that causes the mboxt implementation to > be selected by default was missing, causing the mboxt2 implementation > to be used all the time. Before looking at this I would have sworn > that mboxt was the default implementation. > > I have therefore added the option and set it to select the mboxt > implementation, which is what should have been happening all along. It > also appears that using mboxt also solves the problems that were > reported for LWIP. > > However: switching from mboxt2 to mboxt does introduce a slight change > in semantics for mailboxes. It only affects mailboxes that have > multiple threads attempting to get messages simultaneously. I believe > it is reasonable to commit this since it doesn't violate the specified > behaviour, and it results in using a slightly smaller > implementation. It has required a change to the test programs, but > that's because they attempt to track mailbox behaviour in an > unsynchronized way. > > > Before committing this, I think we need to come to a consensus as to > whether this difference in behaviour is in fact significant.
This has now been committed. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts >>>> Visit us on stand 104 at The Embedded Systems Show 2006, NEC <<<< >>>> Oct 11-12 Birmingham, UK http://www.edaexhibitions.com/ess/ <<<<
