Re: [lwip-users] critical section protection + timer issues questions

[Jim Gibbons]

I don't think that you will have any problems.  In our designs, we do not use any of the sys.c stuff for our own threads.  It works fine.

The only threads that need to use the sys.c stuff are those that want to have associated sys_timeout callbacks.  TCP/IP is one such thread.  It wants to have an associated sys_timeout to operate its tcp_tmr.

Let me try to construct another example of a thread that you might have that would utilize sys_timeout calls.  Let's say for example that you want to have a thread pending on a semaphore and reporting via TCP the state of a collection of A/D converters.  No problems with either the underlying OS or with sys_sem.  Now let's also imagine that you want the A/D converters to be sampled periodically and averaged, and that you want that averaged results to be reported in a self consistent set via TCP, upon receipt of the semaphore posting.  In this instance, you could use sys_timeout within the context of the thread pending on the semaphore to govern the A/D sampling and averaging.  By doing so, you could be assured that the A/D sampling and averaging was running in the same task context as your TCP reporting functions, so you wouldn't need a mutex to protect the average value storage locations.

Now let me construct an example of a thread that wouldn't use the sys.c stuff at all.  It's closely related to the one above, but the A/D sampling is made much simpler.  Let's say that you have really fast A/D's and that you don't need to do any sampling.  You just want to pend on a semaphore, and when it is posted, you want to collect data from your A/D's and report it.  You don't have any need of any time related behavior, so you have no motivation to use sys_timeout.  You don't need to use any sys.c stuff in such a task.

I hope I've been able to make the point clearly that the sys.c services needn't be used in all tasks.  You can elect to use them in some of your tasks and not in others.  The key to this is making sure that the initial sys_timeout call is made in the correct task context for each of your timers, and that this subset of your tasks uses the sys_sem, sys_mbox and sys_mssleep functions.

Scott Taggart wrote:

Jim,

Again, thanks for your responses.  I was fine until you wrote this which is confusing (maybe it’s semantics) because it sort of implies that I don not have to end up in sys.c to block:

“The sys.c is really just a wrapper for the underlying OS's semaphore, mailbox and sleep methods.  If the underlying OS methods are what you need, the wrapper should also work just fine for you.  If you use the wrapper functions, you get the timers as a bonus.  This may be just what you need - or it may not be.  If it is what you need, then you can use sys_timeout and you won't need to build anything else of your own.  If these methods aren't what you need, but the underlying OS does support you, then you just have to do your own thing with regards to timers.  The sys.c may prove to be a convenience to you, but if they aren't you then they shouldn't constitute a design restriction.  They're just tools that you can use if you find them handy.”

I think you might have misunderstood what I was griping about.  It’s not that I need to use or avoid underlying o/s services and that the sys.c stuff may give me a convenient interface.  It’s that I NEVER want to have to call the sys.c stuff from my threads (i.e., if I want a thread that has an LWIP TCP connection open, I want to call the O/S’s underlying, native semaphore and mutex calls to block when I want to).  I do not want my threads to HAVE to call into the sys.c stuff JUST to get the LWIP timer stuff to function.  As it is, I see no other work-around – because the LWIP timer stuff DEMANDs that all threads block in the previously mentioned 3 calls, I see no choice.  I find this incredibly restrictive and arrogant – to presume that all threads on all o/ss must end up in some internal LWIP function call for the stack to work.  Again, if I am missing something, I would love to know it.  Another way to state this is that I just don’t understand why the LWIP implementer(s) did not require a form of timer callback and that they didn’t just deal with the critical section issues, as required.  OK, so it’s free and it was designed to run on a small embedded enviroment and not on every o/s.  Still seems like an odd design restriction to me.

Thanks,

Scott

_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users

--

Jim Gibbons	address@hidden
Gibbons and Associates, Inc.	TEL: (408) 984-1441
900 Lafayette, Suite 704, Santa Clara, CA	FAX: (408) 247-6395