Re: Threadsanitizer Detection on GM

On Wed, 13 Feb 2019, Hongxu Chen wrote:

> Hi Bob,
>
>    I think TSan warns not because of the atomic increment for row_count,
> but the interleaving between the write of row_count (line 123) and the read
> of it (line 124). It's possible to have the following interleavings
> where row_count is different.

Does an 'omp flush' of row_count help?  Does Threadsanitizer 
understand 'omp atomic' and 'omp flush'?  These constructs are using 
CPU/hardware features to assure that all threads get the updated 
value rather than blocking while one thread updates it and then doing 
an implicit flush so that all threads see the change.

> Therefore the differences of row_count can lead to different branchings
> even if all the execution traces before entering line 123 are all the same.
> Additionally, MagickMonitorFormatted also read row_count, which may finally
> affect the "thread_status=MagickFail" assignment.

The value of row_count used by MagickMonitorFormatted() is passed by 
value so I don't see how it can read a different value of row_count 
than when it was originally prepared.

Bob