Re: Questions about Tsan and Tsanv3
88 views
Skip to first unread message
Marco Elver
Jun 30, 2023, 6:32:55 AM6/30/23
to Hünkar Can Tunç, thread-sanitizer, Dmitry Vyukov, uma...@nus.edu.sg, Yifan Dong, Andreas Pavlogiannis
+Cc thread-sanitizer mailing list
On Fri, 30 Jun 2023 at 12:24, Hünkar Can Tunç <tu...@cs.au.dk> wrote:
>
> Dear Marco and Dmitry,
>
> If possible, I wanted to ask a question here which directly relates to something that Marco has mentioned in earlier emails, but I'm also happy to move this conversation to the thread-sanitizer mailing list.
>
> It was mentioned earlier that TSan v3 introduced a new usage scheme for vector clocks:
>
> One major change in TSan v3 is that vector clocks no longer contain #num_threads entries. Instead, they represent some fixed number of "virtual CPUs", where several threads may map to a single "virtual CPU". In practice, it turns out, there are no false positives due to batching a single thread onto a "vCPU" (at least none we detected across numerous projects within and outside Google, along with TSan's test suite). TSan v3 also includes some cleverness to map threads onto "free" vCPUs, so that the risk of this is minimized
This was probably meant to say "false negatives" instead of "false
positives", sorry for the confusion.
> I wanted to ask if there's any documentation that describes the details of how this approach works. From my understanding of this approach, it's not clear to me how it would introduce false positives. I was wondering if you perhaps had an example which conceptually shows how a false positive might be introduced.
>
> In my opinion, a drawback of the above approach is potentially more false negatives. In my experimentation, while I wasn't able to come up with any examples that lead to a false positive, I was able to generate several examples where due to the batching TSan misses data races (both among the threads that is batched into the same slot, and between one of the batched threads and some other thread). I was wondering if you have performed any analysis on the effect of this optimization on false negatives.
On Fri, 30 Jun 2023 at 12:24, Hünkar Can Tunç <tu...@cs.au.dk> wrote:
>
> Dear Marco and Dmitry,
>
> If possible, I wanted to ask a question here which directly relates to something that Marco has mentioned in earlier emails, but I'm also happy to move this conversation to the thread-sanitizer mailing list.
>
> It was mentioned earlier that TSan v3 introduced a new usage scheme for vector clocks:
>
> One major change in TSan v3 is that vector clocks no longer contain #num_threads entries. Instead, they represent some fixed number of "virtual CPUs", where several threads may map to a single "virtual CPU". In practice, it turns out, there are no false positives due to batching a single thread onto a "vCPU" (at least none we detected across numerous projects within and outside Google, along with TSan's test suite). TSan v3 also includes some cleverness to map threads onto "free" vCPUs, so that the risk of this is minimized
This was probably meant to say "false negatives" instead of "false
positives", sorry for the confusion.
> I wanted to ask if there's any documentation that describes the details of how this approach works. From my understanding of this approach, it's not clear to me how it would introduce false positives. I was wondering if you perhaps had an example which conceptually shows how a false positive might be introduced.
>
> In my opinion, a drawback of the above approach is potentially more false negatives. In my experimentation, while I wasn't able to come up with any examples that lead to a false positive, I was able to generate several examples where due to the batching TSan misses data races (both among the threads that is batched into the same slot, and between one of the batched threads and some other thread). I was wondering if you have performed any analysis on the effect of this optimization on false negatives.
Marco Elver
Jul 3, 2023, 8:47:50 AM7/3/23
to Hünkar Can Tunç, thread-sanitizer, Dmitry Vyukov, uma...@nus.edu.sg, Yifan Dong, Andreas Pavlogiannis
On Fri, 30 Jun 2023 at 12:32, Marco Elver <el...@google.com> wrote:
> > In my opinion, a drawback of the above approach is potentially more false negatives. In my experimentation, while I wasn't able to come up with any examples that lead to a false positive, I was able to generate several examples where due to the batching TSan misses data races (both among the threads that is batched into the same slot, and between one of the batched threads and some other thread).
This change shows the new implementation changes:
> > In my opinion, a drawback of the above approach is potentially more false negatives. In my experimentation, while I wasn't able to come up with any examples that lead to a false positive, I was able to generate several examples where due to the batching TSan misses data races (both among the threads that is batched into the same slot, and between one of the batched threads and some other thread).
https://reviews.llvm.org/D112603 - to better understand how the
current implementation allocates slots, you could start at the
function FindSlotAndLock(). Slot allocation is dynamic, and tries to
find an unused slot first.
> I was wondering if you have performed any analysis on the effect of this optimization on false negatives.
many millions of tests wrt false negatives.
Thanks,
-- Marco
Reply all
Reply to author
Forward
0 new messages