lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] multithreaded app ...


From: Teratux
Subject: Re: [lwip-users] multithreaded app ...
Date: Wed, 23 Jun 2010 07:58:24 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4

It's some of the same. If a connection has to be shared among two threads and the receiving threads blocks the connection until something arrives you would have to change execution over to the writing thread. My idea was to create a simple watchdog mechanism. It works with a third thread that monitors the read and write threads. These in turn, upon execution, notify the watchdog periodically. If either the read thread blocks waiting, or the write thread has nothing to transmit the watchdog switches over to the other waiting thread. You can't use mutexes in this case, when you suspend a thread you can't free the taken mutex.

I'm having another bug on my app that I haven't been able to sort out, but I'll keep on working on it ... Thanks for all the information provided here regarding multithreads and lwip .... :)

On 06/22/10 15:17, Bill Auerbach wrote:
Yeah, I guess if it were easy to do they would have done it :-)

Isn't not blocking on a read a different problem altogether over using netconns 
or sockets in multiple threads?  Or do you mean you would need reading 
semaphores or writing semaphores?  In any case, my suggestion was only written 
because this threading problem comes up often.

Bill

-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Teratux
Sent: Tuesday, June 22, 2010 10:41 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] multithreaded app ...

I think the problem goes a bit farther.  netconn_recv blocks waiting for
a connection.  Even if I use a mutex to exclude between the threads that
write and read, how can I use netconn_recv in a way that it doesn't
block if there's no one sending on the other end ?? Is there anything
like a timeout for the netconn_recv call ??

Thanks ...

On 06/22/10 08:24, Bill Auerbach wrote:
Since this threading problem comes up weekly it seems, would it be a
lot of effort to add an LWIP_MULTITHREADED option and add the semaphore
locks in the functions to ensure no reentrancy in lower lwIP code?  I
would think 2 simple macros that can expand to nothing or semaphore
lock/unlocks could be added to all of the functions making lower level
calls.  Or possibly, call a single locking function passing in the
function pointer to call after locking.  This might be tricky with
arguments I know.
Bill


-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Simon Goldschmidt
Sent: Tuesday, June 22, 2010 5:07 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] multithreaded app ...


Kesten, Joerg wrote:

Additionally we needed to prevent simultaneous calls to "send" even
on
different sockets. We added a mutex in the send function itself ...

This shouldn't be necessary. If it is, there's a bug which should be
fixed. Could you provide more details on what exactly went wrong with
parallel sends from different netconns/sockets?

Simon
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

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


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

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




reply via email to

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