Dear Simons Thats a better way and i have also used it and created my own sequential APIs using this locking mechanism .This helped me to get a BSD style socket api with the approximate performance of raw api .
Mumtaz Ahmad Network Systems Group ----- Original Message ----- From: "Christiaan Simons" <[EMAIL PROTECTED]> To: "Mailing list for lwIP users" <[email protected]> Sent: Friday, November 17, 2006 5:39 PM Subject: Re: [lwip-users] Bug in pbuf.c regarding PBUF_POOL > @Jonathan: > > > > We have a proven real-time pre-emptive design (even with nested > > > pre-emptable interrupts) that does not use SYS_LIGHTWEIGHT_PROT but > uses > > > the "bottom-half" approach. > > > > I would be surprised if it were truly thread-safe given my understanding > of > > the current code. Maybe it used to be with different earlier code. But I > > haven't seen the code for that port. > > What we do is truly thread safe, > since we protect the calls to the _raw-API_. > > As Leon said the interrupt top half merely > wakes a high priority task (bottom half) on eth rx. > > This task locks a (uCOS) mutex, copies data from the > ethernet controller and pushes this into the lwIP stack. > After lwIP is done we unlock this mutex. > > Other tasks accessing to any lwIP structure > are allowed when the mutex is available. > > We completely avoid the lwIP socket or sequential API, > therefore we don't require the troublesome lwIP > "protection". > > Any finer grained locking would require > improved thread safety many places in the current > code as many observed correctly before. > > BTW direct pbuf pool access is desirable > for raw-API applications, such as SNMP. > > Christiaan Simons > > Hardware Designer > Axon Digital Design > > http://www.axon.tv > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
