From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7778 invoked by alias); 24 Oct 2014 12:54:21 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 7768 invoked by uid 89); 24 Oct 2014 12:54:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Oct 2014 12:54:19 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 84B978E1434; Fri, 24 Oct 2014 14:54:16 +0200 (CEST) Date: Fri, 24 Oct 2014 12:54:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Threads Message-ID: <20141024125416.GK20607@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <54450835.3050602@cornell.edu> <5448E6F9.8040005@dronecode.org.uk> <5448EEBF.3020706@cornell.edu> <20141023153730.GC20607@calimero.vinschen.de> <544A327E.9090006@dronecode.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OOq1TgGhe8eTwFBO" Content-Disposition: inline In-Reply-To: <544A327E.9090006@dronecode.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014-10/txt/msg00394.txt.bz2 --OOq1TgGhe8eTwFBO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3125 On Oct 24 12:05, Jon TURNEY wrote: > On 23/10/2014 16:37, Corinna Vinschen wrote: > >On Oct 23 08:04, Ken Brown wrote: > >>Yes, flags register corruption is exactly what Eli suggested in the oth= er > >>bug report I cited. > > > >The aforementioned patch was supposed to fix this problem and it is > >definitely in the current 1.7.32 release... >=20 > I didn't mean to suggest otherwise, just that perhaps a similar problem > exists now. >=20 > So I made the attached test case to explore that. Maybe I've made an > obvious mistake with it, but on the face of it, it seems to demonstrate > something... >=20 > jon@tambora / > $ gcc signal-stress.c -Wall -O0 -g >=20 > jon@tambora / > $ ./a > failed: 2144210386 isn't equal to 2144210386, apparently So it checks i and j for equality, fails, and then comes up with "42 isn't equal to 42"? This is weird... > Note there is some odd load dependency. For me, it works fine when it's t= he > only thing running, but when I start up something CPU intensive, it often > fails... That's... interesting. I wonder if that only occurs in multi-core or multi-CPU environments. The fact that i and j are not the same when testing, but then are the same when printf is called looks like a out-of-order execution problem. Is it possible that we have to add CPU memory barriers to the sigdelayed function to avoid stuff like this? Corinna > #include > #include > #include > #include >=20 > long SmartScheduleInterval =3D 1; /* ms */ > long SmartScheduleTime =3D 0; >=20 > static void > SmartScheduleTimer(int sig) > { > if (sig !=3D 0) > SmartScheduleTime +=3D SmartScheduleInterval; > } >=20 > void > SmartScheduleStartTimer(void) > { > struct itimerval timer; > timer.it_interval.tv_sec =3D 0; > timer.it_interval.tv_usec =3D SmartScheduleInterval * 1000; > timer.it_value.tv_sec =3D 0; > timer.it_value.tv_usec =3D SmartScheduleInterval * 1000; > setitimer(ITIMER_REAL, &timer, 0); > } >=20 > int main() > { > /* Set up the timer signal function */ > struct sigaction act; > act.sa_handler =3D SmartScheduleTimer; > sigemptyset(&act.sa_mask); > sigaddset(&act.sa_mask, SIGALRM); > if (sigaction(SIGALRM, &act, 0) < 0) { > perror("sigaction failed"); > return -1; > } >=20 > /* start timer */ > SmartScheduleStartTimer(); >=20 > /* Loop forever, doing tests which should always succeed, with lots of= signals */ > int x =3D 0; > int i =3D 0; > while (1) { > x =3D i; > int j =3D x; > if (j !=3D i) > { > printf("failed: %d isn't equal to %d, apparently\n", i, j); > break; > } > i++; > } > return 0; > } > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --OOq1TgGhe8eTwFBO Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUSkv4AAoJEPU2Bp2uRE+gPNAP/0+6KVQY8ikTCfETfpaeutkP uIO+Y0Dt3kKe6vxvEXOZdJKjEqka/7Hk7uXldGQJuiiK21VBfKIrIadIE56+IIld vxMX4GLS4AIWEiEpvbb2Mj+iUJ33zBB+5BTqK71VYR2Ok3XNLJlS6obJ96GCkmSp nOPfK48Zc6GHtFRwnXqrMy2lWqPh/P8H/PCVhx7oiLV/T7H89rItpCuW7pTrcce4 xaAbEk55fhaIdWtBjFeScunenofRO6B6FT9FI3JJS/uiuILiGTj6+awI5Qwt1xA1 ayQ6oc5PDvW8typO+YidH6hqLwENsuh+skSFUdSSlk1RimN3JO0Ikt2OCM98aLrj mrK4d6iIvWq0EjGl9ONJQ3RzyjlgoKTZ3XZ4bxHGMOYKRX35CtS4M9LGQ+uqJ0Gc ahnNqolfKk0YUHyfsDx0CL6PeVnem3nUNbGCPsGJz0mhyF51YFLqg3zLVoujYStR 9kU05xPM/Wz2S/3tRWilTZncouXMoiAU2BIMJigvA+tWjxWdQzIri0OVzODKPibN oP9GypdyqaW2SvVfFGGSJfUOptpA8jQhmCgDOEnRh64stA2lQI/jzO09l+C7YHEU BX4wal7LPcn8tuhkzblJDZQ/EXekFGbsMnXTZ8w4dG4tOQ8oeSpGccudQ8ukdL2F VTp6CZm1oqyvDBS4ZoEb =FGX6 -----END PGP SIGNATURE----- --OOq1TgGhe8eTwFBO--