[PATCH] D21889: [tsan] Add support for GCD IO channels on Darwin

[Dmitry Vyukov via llvm-commits]

dvyukov added inline comments.

================
Comment at: lib/tsan/rtl/tsan_libdispatch_mac.cc:528
@@ +527,3 @@
+  };
+  Release(thr, pc, (uptr)channel);
+  REAL(dispatch_io_barrier)(channel, new_block);
----------------
kubabrecka wrote:
> kubabrecka wrote:
> > dvyukov wrote:
> > > Documentation says:
> > > 
> > > The barrier operation applies to the channel’s file descriptor and not to a specific channel. In other words, if multiple channels are associated with the same file descriptor, a barrier operation scheduled on any of the channels acts as a barrier across all of the channels. All previously scheduled operations on any of those channels must complete before the barrier block is executed.
> > > 
> > > But here you synchronize on channel address. So I guess we will have some false positives.
> > > 
> > > Do you release on channel in read/write to synchronize with barriers? If so, it seems to be exactly the kind of reader/writer synchronization we added for barriers recently. Can we reuse that machinery? It captures precisely who needs to synchronize with whom.
> > The io_barrier is a bit more tricky, since it’s not submitted to the same queue as the read&write callbacks, so user’s shouldn’t be using this to synchronize with their code.  So I basically only care about synchronizing submission and execution.
> Ah, so the issue is that we don’t have a dispatch_queue_t parameter here, so we can’t simply use the regular dispatch_callback_wrap...
dispatch_callback_wrap uses dispatch_queue_t only as synchronization address and to understand if the queue is serial or not.

What about adding is_serial to tsan_block_context_t, and then having 2 AllocContext's: one takes dispatch_queue_t and uses IsQueueSerial(q); second -- just takes uptr addr and bool is_serial from caller?



http://reviews.llvm.org/D21889