From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23386 invoked by alias); 5 Jan 2015 20:58:53 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 23374 invoked by uid 89); 5 Jan 2015 20:58:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: resqmta-po-02v.sys.comcast.net Received: from resqmta-po-02v.sys.comcast.net (HELO resqmta-po-02v.sys.comcast.net) (96.114.154.161) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 05 Jan 2015 20:58:51 +0000 Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-02v.sys.comcast.net with comcast id cLwD1p0065Geu2801LynVs; Mon, 05 Jan 2015 20:58:47 +0000 Received: from [IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d] ([IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d]) by resomta-po-20v.sys.comcast.net with comcast id cLyl1p0072ztT3H01LymCn; Mon, 05 Jan 2015 20:58:47 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C From: Mike Stump In-Reply-To: Date: Mon, 05 Jan 2015 20:58:00 -0000 Cc: Jakub Jelinek , "H.J. Lu" , "gcc-patches@gcc.gnu.org" , Dmitry Vyukov Content-Transfer-Encoding: quoted-printable Message-Id: References: ,<3C12133C-DABF-40FA-94F7-9DB785F6E914@comcast.net>,,,<623A5348-6FC9-4F7B-A9BC-B2B098AF7D37@comcast.net>,<20150104191658.GK1667@tucnak.redhat.com> ,<8E43F8AA-96BA-47A3-A886-C058459B4108@comcast.net> To: Bernd Edlinger X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00159.txt.bz2 On Jan 5, 2015, at 12:49 AM, Bernd Edlinger wro= te: > On Sun, 4 Jan 2015 14:18:59, Mike Stump wrote: >>=20 >>> But tsan still gets at least 90% chance to spot that. As a matter of fa= ct, the tsan runtime is just _incredibly_ fast, >>> and catches errors, with a very high reliability. But it is racy by des= ign. >>=20 >> You say by design. I=92m skeptical of that. Can you quote the email or t= he code were they said I wanted to design a system that wasn=92t 100% relia= ble, because the best they could do was 2% slower, and they didn=92t want i= t to be 2% slower? I tend to think someone didn=92t figure out they could a= tomically, locklessly do the update, or they didn=92t understand the perfor= mance hit on the lockless code was small, or worse, they had no clue it was= racy. I=92d be curious to know. Maybe, there are other complications that = prevent it from being non-racy. >=20 > see for instance this thread "Is TSan an exact tool?": > https://groups.google.com/forum/#!topic/thread-sanitizer/mB73m6Nltaw Yeah, that=92s not the issue. The issue is, in this one narrow case, was i= s possible to use a lockless method of updating the data so that the tool w= ould be slightly better. That post doesn=92t address this question. For e= xample, if a patch were submitted to locklessly update so both can notice w= ho is first, was it rejected and why? Anyway, that=92s a side issue, and w= e can safely ignore it. I=92m fine with making testing reliable with how i= t works today. > Nevertheless I would prefer to silence the test now with sleep(1), > And come back later with a follow-up patch to use a un-instrumented and > non-interceptable synchronization primitive in all tsan tests. As it is a= t least > not obvious how to do that in the test suite. But it must be possible. I thought the code was posted, I thought how to put it in a file was posted= . I think it is a 2 minute endeavor to put all those pieces together and r= un a test case? You do know how to run just 1 tsan test case with make RUN= TESTFLAGS=3Dtsan.exp=3Daligned_vs_unaligned_race.C check-g++ sort of thing?= This can shorten the testing time from hours per iteration to seconds per= iteration. Slightly non-obvious, but very handy when developing some type= s of test cases. So, to help you out, I tried my hand at wiring up the extra library code: gcc/gcc/testsuite/gcc.dg/tsan$ cat test1.c /* { dg-additional-options "-O2" } */ /* { dg-additional-sources "lib.c" } */ void sync(int); int main(int argc, char**argv) { sync(1); sync(2); sync(3); } gcc/gcc/testsuite/gcc.dg/tsan$ cat lib.c /* { dg-do compile } */ #include volatile int serial; __attribute__((no_sanitize_address)) void sync(int i) { while (serial !=3D i-1) ; while (1) { if (++serial =3D=3D i) return; --serial; sleep (); } } and it ran just fine. The options are for both files. I read some of the = tsan documentation, and they seem to claim you can have tsan not process a = function by merely asking. I did that. I don=92t know if that is enough t= o hide all the semantics that need to be hidden. In the above code, the ++ and -- should be an atomic increment/decrement. The idea is that can can introduce a deterministic ordering to the executio= n of the code by adding sync(n), where n is the step number, whose range st= arts at 1. So, for example, here is the test case, with the bits added, so you can see= how I transformed what would have been the sleep into the use of the synch= ronizing primitive from the library. /* { dg-additional-sources "lib.c" } */ /* { dg-shouldfail "tsan" } */ #include #include #include #include void sync(int); uint64_t Global[2]; void *Thread1(void *x) { sync (2); Global[1]++; return NULL; } void *Thread2(void *x) { char *p1 =3D reinterpret_cast(&Global[0]); struct __attribute__((packed, aligned(1))) u_uint64_t { uint64_t val; }; u_uint64_t *p4 =3D reinterpret_cast(p1 + 1); (*p4).val++; sync (1); return NULL; } int main() { pthread_t t[2]; pthread_create(&t[0], NULL, Thread1, NULL); pthread_create(&t[1], NULL, Thread2, NULL); pthread_join(t[0], NULL); pthread_join(t[1], NULL); printf("Pass\n"); /* { dg-output "WARNING: ThreadSanitizer: data race.*(\n|\r\n|\r)" } */ /* { dg-output "Pass.*" } */ return 0; } The question is, does this 100% reliably solve the problem?