lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [bug #1902] Timeouts and semaphores/mailboxes are too tight


From: Simon Goldschmidt
Subject: [lwip-devel] [bug #1902] Timeouts and semaphores/mailboxes are too tightly integrated
Date: Sun, 13 May 2007 10:01:28 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Follow-up Comment #21, bug #1902 (project lwip):

OK, I've had a little time to create a new version of sys.h/sys.c (attaching
the 2 new files instead of a patch) with the following changes to the
original sys layer:

- semaphore functions don't check timers
- all time-related processing is done in jiffies rather than ms to avoid
frequent converting
- converting is done through
SYS_ARCH_JIFFIES_TO_MS()/SYS_ARCH_MS_TO_JIFFIES() macros

Changes for the ports:
- SYS_ARCH_JIFFIES_TO_MS() / SYS_ARCH_MS_TO_JIFFIES() need to be defined in
sys_arch.h
- lwip_timestamp_t (unsigned) and lwip_timediff_t (signed) need to be
typedef'ed or defined in cc.h
- mbox and semaphore functions in sys_arch.c get their timeout arguments as
jiffies, so don't need to convert any more
- the function sys_jiffies() has to be implemented (returns the jiffies in
lwip_timestamp_t)

What remains to be determined
- do we need sys_msleep() as it was (using a timer rather than simply using
the OSes sleep-function)? In other words: do timers have to run while
sleeping?
- no check for overflow is done, that either relies on a working port or
remains to be done, I'm not quite sure where to check it... Maybe we could
need 2 defines: SYS_ARCH_MAX_JIFFIES and SYS_ARCH_MAX_MS to check against
when calling a timeout function (create timer / mbox_fetch / sem_wait). This
is because if JIFFIES_PER_MS < 1 (e.g. ticks per second < 1000),
SYS_ARCH_MAX_JIFFIES is what limits a maximum sleep value; but if
JIFFIES_PER_MS > 1 (e.g. with a high resolution hardware timer),
SYS_ARCH_MAX_SECONDS is what limits a maximum sleep. Because if the hardware
timer wraps around at 0xffffffff (max 32bit) and you have to multiply ms by
4000 (as I have to) to get the hw-timer-ticks, the max-wait-time is only
0x10624D instead of 0xffffffff. Hm, I think I did not formulate this very
clear, but that's how it is! ;-)


Finally 2 speedup issues:
- I tried to design the code in a way that defining SYS_ARCH_JIFFIES_TO_MS()
& SYS_ARCH_MS_TO_JIFFIES() as macros using constants should lead to
conversion at compiletime instead of converting at runtime
- As Frédéric has proposed, replacing sys_mbox_fetch calls in the api layer
by sys_arch_mbox_fetch (e.g. not using timers in a non-core thread) should
give a better performance. Personally, I think this is a good idea.

Oh, and if this goes on too long before making progress, maybe we should take
out the timer processing from the semaphore functions as a separate action
now? It seems to me this is rather unrelated to a faster/more accurate way of
timestamp processing... And it does lead to problems!

(file #12761, file #12762)
    _______________________________________________________

Additional Item Attachment:

File name: sys.c                          Size:9 KB
File name: sys.h                          Size:8 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?1902>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/





reply via email to

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