lwip-members
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-members] Seems Error to me!!


From: Jack Carlson
Subject: Re: [lwip-members] Seems Error to me!!
Date: Wed, 25 Jun 2003 20:58:39 -0700 (PDT)

Hi Kieran,
      I think we are singing two different songs. Look what my doubt is:- that no body is decrementing the count of last so after posting more than SYS_MBOX_SIZE no. of messages the task which is posting the message will block each time it wants to post a message(irrespective of whether the TCPIP thread has read all the messages). Plz see the following code and kindly check if it matches ur code:-
 
void
sys_mbox_post(struct sys_mbox *mbox, void *msg)
{
  u8_t first;
 
  sys_sem_wait(mbox->mutex);
 
  DEBUGF(SYS_DEBUG, ("sys_mbox_post: mbox %p msg %p\n", (void *)mbox, (void *)msg));
 
  while ((mbox->last + 1) >= (mbox->first + SYS_MBOX_SIZE)) {
    mbox->wait_send++;
    sys_sem_signal(mbox->mutex);
    sys_arch_sem_wait(mbox->mail, 0);
    sys_arch_sem_wait(mbox->mutex, 0);
    mbox->wait_send--;
  }/*Amit if the last message exceeds the tail wait till the messages are read by the TCP task*/
 
  mbox->msgs[mbox->last % SYS_MBOX_SIZE] = msg;
 
  if (mbox->last == mbox->first) {
    first = 1;
  } else {
    first = 0;
  }
 
  mbox->last++;
 
  if (first) {
    sys_sem_signal(mbox->mail);
  }
  sys_sem_signal(mbox->mutex);
}
 
In the while loop the message posting thread blocks each time after it exceeds the length. irrespective of if the TCPIP thread has already read the messages.(this is bcoz no one is decrementing the count). I really could understant the posting of message and fetching of the message.
but this blocking seems a problem to me.
Regards
Jack
 
 
 
 
 

Kieran Mansley <address@hidden> wrote:
On Tue, 24 Jun 2003, Jack Carlson wrote:

> Hi Kieran ,
> I am Using the latest version i guess it is 1.6.3 the following
> line in the function sys_mbox_post :-
> ((mbox->last + 1) >= (mbox->first + SYS_MBOX_SIZE)) mean that the
> message queue is already full and the posting thread has to block to
> give the TCPIP thread chance to read some messages from the queue. If
> you do not decrement the count after the maximum messsage posted by the
> thread each time the posting thread will unnecessarily block which is
> surely a performance issue. What do u say?? Regards Jack

I've checked the code again, and I can't see a problem.

mbox->first % SYS_MBOX_SIZE gives the index of the first item in the
mbox

mbox->last % SYS_MBOX_SIZE gives the index of the last item in the mbox

If mbox->last is SYS_MBOX_SIZE greater than mbox->first then there are
SYS_MBOX_SIZE items in the mbox (ie. it is full) and the sys_mbox_post()
should block.

Neither mbox->first or mbox->last are ever decremented. Lets say
SYS_MBOX_SIZE is 10, and 13487 messages have been posted, and 13484
messages fetched. ie. mbox->last=13487 and mbox->first=13484. It doesn't
matter that the absolute numbers are much greater than SYS_MBOX_SIZE, as
the absolute values are never used. We always use the % operator to find
the actual index. So, the index of the last message is 13487 % 10 = 7 and
the index of the first message is 13484 % 10 = 4, in this case (13487+1)
is not >= (13484 + 10) so the mbox wouldn't block as expected. If we
posted another 6 messages though, mbox->last would now be 13493. As a
result (13493 + 1) is >= (13484 + 10) and the mbox will block as it should
as it is now full.

I hope you can see what I'm getting at as I'm not sure how else to explain
it!

Are you actually seeing a problem when using the code, or is it just that
while reading it you can't see how it works?

Kieran


Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
reply via email to

[Prev in Thread] Current Thread [Next in Thread]