From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31766 invoked by alias); 15 Sep 2012 17:44:36 -0000 Received: (qmail 31757 invoked by uid 22791); 15 Sep 2012 17:44:34 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,TW_DR X-Spam-Check-By: sourceware.org Received: from bay0-omc3-s2.bay0.hotmail.com (HELO bay0-omc3-s2.bay0.hotmail.com) (65.54.190.140) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 15 Sep 2012 17:44:21 +0000 Received: from BAY146-W64 ([65.54.190.187]) by bay0-omc3-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 15 Sep 2012 10:44:21 -0700 Message-ID: From: Bernd Edlinger To: , Date: Sat, 15 Sep 2012 17:44:00 -0000 In-Reply-To: References: <504b83c0.056f650a.2700.0bdd@mx.google.com>,,,,, Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: RE: [ECOS] BSD socket stall X-SW-Source: 2012-09/txt/msg00019.txt.bz2 Hi Henry, > We will try out this change but we have already changed our application=20 > to have separate sockets for each thread. I not sure we could provide=20 > answer to the question of does this change the fix this issue in our=20 > case.=20 >=20 > I am just surprised that an issue like this could still be the BSD=20 > after all these years. I mean ECOS and freeBSD stack have been out for=20 > what 10+ years. I am I clueless for having assumed having two threads=20 > send one socket was OK. I believed that sockets would be thread save, I=20 > guess that is not the case.=20 > Thanks,=20 > Henry=20 For UDP sockets that use case is perfectly OK. You will see, the new version will handle this correctly, except for the still possible priority inversion. For TCP sockets the results are undefined, except when the message size is always exactly 1 byte. Why did that problem not occur before? Hard to tell. For instance I believe that the problem arises from interrupting this statement in sb_lock(): sb->sb_flags |=3D SB_WANT; that will be an atomic like OR [bx],0x2 on Intel, but at least 3 assembler instructions on ARM. So you should have no problem at all on an Intel. Although this is a perfect example of what happens, when you use a condition object without a mutex. But you should also check for Spurious interrupts. They are likely to occur due to the "Tickle Loop" in the BSD stack, especially when at a high rate. My latest AT91 Ethernet driver does not need this any more, and avoids the spurious interrupts even if the stack polls the IRQ from time to time. Therefore I would recommend you check this list of important patches which we at Softing developed over the last year (I must apologize, the list is too long, but we walk on thin ice as you know, and most of these bug fixes are obviously badly needed): Bug 20804: Misbehavior of printf %e/%g format Bug 1001522: Array index out of bounds in tftp_server.c Bug 1001629: bsd stack uses wrong timeout values if hz !=3D 100 Bug 1001633: DHCP Client may hang Bug 1001634: A code review of dlmalloc.cxx revealed several weaknesses Bug 1001635: wrong results from Cyg_StdioStream::read Bug 1001637: fcntl() fails to handle F_GETFL, F_SETFL Bug 1001639: Problems with i2c.cxx Bug 1001641: Erase function in flashiodev.c and flashiodevlegacy.c handle "= err_address" differently Bug 1001645: Recursive Posix Mutexes Bug 1001648: flash_init() behaves differently if CYGHWR_IO_FLASH_DEVICE=3D= =3D1 Bug 1001649: AT91 hal extension Bug 1001654: diag_printf truncates the values in %llu and %llx formats Bug 1001655: eth_drv_send stack_corruption with CYGFUN_LWIP_MODE_SIMPLE Bug 1001656: FreeBSD: add AF_PACKET socket family Bug 1001657: httpd server should parse request header lines It might help to understand what is the application for this patches, especially the new transacted PHY interface and the Packet sockets. Think of PTPv2: Here we have to exchange very complex data over SMI with the PHY, and the PTP packets may be in raw ethernet format. That is what finally led to these enhancements. Regards, Bernd Edlinger=20=09=09=20=09=20=20=20=09=09=20=20 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss