Re: Mailbox patch

[Nick Garnett <nickg at ecoscentric dot com>]

"Christopher Cordahi" <christopher.cordahi@gmail.com> writes:

> Sorry I'm not replying to original message because I just joined the patches
> mailing list, previously I was only reading the discuss list.
> 
> Nick Garnett wrote:
> 
> > 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 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.
> 
> From my understanding of David's problem described in
> http://ecos.sourceware.org/ml/ecos-discuss/2006-08/msg00200.html
> 
> when the queue contains an item, the following line is executed
> to return the next item from the queue
>        ritem = itemqueue[ (count--, base++) ];
> 
> but when the queue is empty the thread sleeps and there is no corresponding
> line when the thread resumes execution, thus an invalid item is returned

I don't believe this is a problem. It is related to the semantic
difference between the implementations, so see below.


> 
> > However: switching from mboxt2 to mboxt does introduce a slight change
> > in semantics for mailboxes.
> 
> What is the change in semantics?

The main change is the way that messages get handed off to waiting
threads. Consider the following example:

Thread A is performing a get() operation on an empty mailbox and is
therefore suspended on the mailbox's thread queue. Thread B now put()s
a message to the queue.

In the mboxt implementation, Thread B inserts the message into the
mailbox's message queue and wakes up Thread A. Thread A wakes up,
inspects the message queue and finds the message which it then removes
and returns to the caller.

In the mboxt2 implementation, Thread B passes the message directly to
Thread A, stashing it in a location pointed to by a pointer in Thread
A's thread control block. Thread B then wakes Thread A, which can just
return with the message already received.

So far these two implementations are identical in the result. The
difference in semantics occurs when a third higher priority thread,
Thread C, preempts Threads A and B and executes a get() operation on
the mailbox after Thread B has finished but before Thread A runs. In
the mboxt implementation, Thread C will grab the message from the
message queue, which will cause Thread A to see an empty queue and go
back to waiting. In the mboxt2 implementation the message has already
been given to Thread A, so Thread C will be forced to wait.

So the semantic difference is in allocation of messages to Threads A
and C in this situation. Of course there are lots of other things that
may cause the messages to be allocated like this that are independent
of the mbox implementation: Thread B may run a little later, Thread C
may run a little earlier, asynchronous interrupts may cause various
other threads to run and affect relative timings. The window of
opportunity for this semantic difference to show is fairly
small. Programs that have several threads grabbing messages from the
same mailbox cannot make any assumptions about exactly which threads
get which messages, for all of these reasons.

So I believe that switching to the mboxt implementation will not make
any real difference.


This also explains the code in the mboxt2 get() function you mention
above. If the get() function needs to wait, it knows that when it
wakes the put()er has already put a message in the destination
location, so all it needs to do is return.

-- 
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts