[
https://issues.apache.org/jira/browse/STDCXX-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575458#action_12575458
]
Martin Sebor commented on STDCXX-449:
-------------------------------------
There are two potential problems here: word tearing (accessing parts of the
same word non-atomically), and a data race between two conflicting accesses to
the same word. I agree that word-tearing is a non-issue on all our platforms
(some implementations of the Alpha processor had this property -- see this
[article|http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V50_HTML/ARH9RATE/DOCU_007.HTM#gran_wordtear]
but I _think_ that's been fixed in newer versions of the chip/OS). The data
race is what I'm concerned about. I believe the data race is benign if we can
make the assumption that every read will return a value previously written to
the same location. I'm fairly confident this is the case on all implementations
we have access to, but I'm also pretty sure there are architectures out there
where such an assumption isn't safe, i.e., architectures that don't guarantee
that a plain (unordered) read will yield any previously written value when the
accesses take place on different processors. I don't know if such architectures
have been implemented and occur in practice.
In any case, if we're comfortable with limiting this issue to the Intel Thread
Checker errors on i386 (or x86_64), it would be safe to ignore such
architectures. And if we're also comfortable with treating the ITC errors as
benign on i86 we can simply suppress them. I can think of two ways of doing it
without seriously impacting the performance of the code:
* instrument the code by inserting the appropriate #pragmas when compiling with
thread-checking enabled (Intel C++ only), or
* instrument the code by making calls to the appropriate ITC functions at
runtime when the tool is being used or not (i.e., regardless of the compiler)
IMO, the second option is the more robust of the two but I'm not sure how
feasible it is to implement it.
> [ITC/Linux] std::string Write -> Read data-race errors
> ------------------------------------------------------
>
> Key: STDCXX-449
> URL: https://issues.apache.org/jira/browse/STDCXX-449
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 21. Strings
> Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
> Environment: Intel Thread Checker 3.1 on Red Hat Enterprise Linux AS
> release 4 (Nahant Update 4)
> Reporter: Martin Sebor
> Assignee: Travis Vitek
> Priority: Minor
> Fix For: 4.2.1
>
> Attachments: 21.string.cons.mt.itc-report.html
>
>
> Running the Intel Thread Checker on the string thread safety tests
> 21.string.cons.mt and 21.string.push_back.mt produces errors suggesting
> potential thread safety problems even though the tests run successfully to
> completion. See the text output below:
> {noformat}
> $ tcheck_cl -w 200 ./21.string.cons.mt --nloops=100 --nthreads=2
> Intel(R) Thread Checker 3.1 command line instrumentation driver (24400)
> Copyright (c) 2007 Intel Corporation. All rights reserved.
> Building project
> Running: /build/sebor/stdcxx-icc-9.1_042-15s/tests/21.string.cons.mt
> --nloops=100 --nthreads=2
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: Intel C++, __INTEL_COMPILER = 910, __INTEL_COMPILER_BUILD_DATE =
> 20060706, __EDG_VERSION__ = 306
> # ENVIRONMENT: i386 running linux-elf 2.4.20 with glibc 2.3
> # FILE: 21.string.cons.mt.cpp
> # COMPILED: Jun 13 2007, 13:00:49
> # COMMENT: thread safety
> ############################################################
> # CLAUSE: lib.string.cons
> # INFO (S1) (3 lines):
> # TEXT: testing std::string with 2 threads, 100 iterations each
> # CLAUSE: lib.string.cons
> # INFO (S1) (3 lines):
> # TEXT: testing std::wstring with 2 threads, 100 iterations each
> # CLAUSE: lib.string.cons
> # +-----------------------+----------+----------+----------+
> # | DIAGNOSTIC | ACTIVE | TOTAL | INACTIVE |
> # +-----------------------+----------+----------+----------+
> # | (S1) INFO | 3 | 3 | 0% |
> # | (S7) ASSERTION | 0 | 16 | 100% |
> # +-----------------------+----------+----------+----------+
> Application finished
> ________________________________________________________________________________________________________________________________________________________________________________________________________
> |ID |Short Description |Severity |Cou|Context[Best] |Description
>
> |1st Access[Best] |2nd Access[Best] |
> | | |Name |nt | |
>
> | | |
> ________________________________________________________________________________________________________________________________________________________________________________________________________
> |1 |Write -> Read |Error |128|[21.string.cons.mt,|Memory read at
> "_strref.h":159 conflicts with a prior memory write at [21.string.cons.mt,
> |[21.string.cons.mt, |"_strref.h":159 |
> | |data-race | | |0xadf0] |0x3475f] (flow
> dependence)
> |0x3475f] | |
> ________________________________________________________________________________________________________________________________________________________________________________________________________
> |2 |Read -> Write |Error |5 |[21.string.cons.mt,|Memory write
> at [21.string.cons.mt, 0x3475f] conflicts with a prior memory read at
> |"_strref.h":159 |[21.string.cons.mt, |
> | |data-race | | |0x34755]
> |"_strref.h":159 (anti dependence)
> | |0x3475f] |
> ________________________________________________________________________________________________________________________________________________________________________________________________________
> |3 |Thread termination |Information|1 |Whole Program 1 |Thread
> termination at "thread.cpp":76 - includes stack allocation of 10.004 MB and
> use of |"thread.cpp":76 |"thread.cpp":76 |
> | | | | | |4.516 KB
>
> | | |
> ________________________________________________________________________________________________________________________________________________________________________________________________________
> |4 |Thread termination |Information|1 |Whole Program 2 |Thread
> termination at "thread.cpp":76 - includes stack allocation of 10.004 MB and
> use of |"thread.cpp":76 |"thread.cpp":76 |
> | | | | | |4.516 KB
>
> | | |
> ________________________________________________________________________________________________________________________________________________________________________________________________________
> |5 |Read -> Write |Error |7 |[21.string.cons.mt,|Memory write
> at [21.string.cons.mt, 0x3475f] conflicts with a prior memory read at
> |"_strref.h":159 |[21.string.cons.mt, |
> | |data-race | | |0x34755]
> |"_strref.h":159 (anti dependence)
> | |0x3475f] |
> ________________________________________________________________________________________________________________________________________________________________________________________________________
> |6 |Thread termination |Information|1 |Whole Program 3 |Thread
> termination at "thread.cpp":76 - includes stack allocation of 10.004 MB and
> use of |"thread.cpp":76 |"thread.cpp":76 |
> | | | | | |4.516 KB
>
> | | |
> ________________________________________________________________________________________________________________________________________________________________________________________________________
> |7 |Thread termination |Information|1 |Whole Program 4 |Thread
> termination at "thread.cpp":76 - includes stack allocation of 10.004 MB and
> use of |"thread.cpp":76 |"thread.cpp":76 |
> | | | | | |4.516 KB
>
> | | |
> ________________________________________________________________________________________________________________________________________________________________________________________________________
> |8 |Thread termination |Information|1 |Whole Program 5 |Thread
> termination at "21.string.cons.mt.cpp":237 - includes stack allocation of 10
> MB and |"21.string.cons.mt.c|"21.string.cons.mt.cpp|
> | | | | | |use of 8.578
> KB
> |pp":237 |":237 |
> ________________________________________________________________________________________________________________________________________________________________________________________________________
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
