Re: Mailbox patch

["Christopher Cordahi" <christopher dot cordahi at gmail dot com>]

On 14 Sep 2006 10:48:01 +0100, Nick Garnett <nickg@ecoscentric.com> wrote:
> "Christopher Cordahi" <christopher.cordahi@gmail.com> writes:
>
> > 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.

OK, thanks, sorry for any confusion

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

Yes I agree, they basically are the same.
If I understand correctly, the mboxt implementation decides which thread should
receive a message at the time a get thread is to be released, whereas the mboxt2
implementation decides which thread should receive a message while the thread
doing the put is still running.
Is this distinction important for UITRON compatibility?

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

OK, I now understand the get function, but could there still be a
problem in the put or in which thread is released.  Based on David's
observations, the mboxt2 implementation seemed to lose data
and receive garbage, whereas the mboxt implementation worked
reliably.  Oh, btw, David was my colleague here at Nanometrics.

--
Chris