State of support for the ISO C++ Transactional Memory TS and remanining work
Wed Nov 11 15:04:00 GMT 2015
On 10/11/15 18:29, Torvald Riegel wrote:
> On Tue, 2015-11-10 at 17:26 +0000, Szabolcs Nagy wrote:
>> On 09/11/15 00:19, Torvald Riegel wrote:
>>> I'd like to summarize the current state of support for the TM TS, and
>>> outline the current plan for the work that remains to complete the
>>> Attached is a patch by Jason that implements this check. This adds one
>>> symbol, which should be okay we hope.
>> does that mean libitm will depend on libstdc++?
> No, weak references are used to avoid that. See libitm/eh_cpp.cc for
>>> I've not yet created tests for the full list of functions specified as
>>> transaction-safe in the TS, but my understanding is that this list was
>>> created after someone from the ISO C++ TM study group looked at libstdc
>>> ++'s implementation and investigated which functions might be feasible
>>> to be declared transaction-safe in it.
>> is that list available somewhere?
> See the TM TS, N4514.
i was looking at an older version,
things make more sense now.
i think system() should not be transaction safe..
i wonder what's the plan for getting libc functions
instrumented (i assume that is needed unless hw
support is used).
>> the runtime exits on memory allocation failure,
>> so it is not possible to use it safely.
>> (i think it should be possible to roll back the
>> transaction in case of internal allocation failure
>> and retry with a strategy that does not need dynamic
> Not sure what you mean by "safely". Hardening against out-of-memory
> situations hasn't been considered to be of high priority so far, but I'd
> accept patches for that that don't increase complexity signifantly and
> don't hamper performance.
i consider this a library safety issue.
(a library or runtime is not safe to use if it may terminate
the process in case of internal failures.)
>> GTM_error, GTM_fatal
>> the runtime may print error messages to stderr.
>> stderr is owned by the application.
> We need to report errors in some way, especially with something that's
> still experimental such as TM. Alternatives are using C++ exceptions to
> report errors, but we'd still need something else for C, such as
> handlers that the program can control.
ok, i thought the plan was to move this out of the
experimental state now.
>> uint64_t GTM::gtm_spin_count_var = 1000;
>> i guess this was supposed to be tunable.
>> it seems libitm needs some knobs (strategy, retries,
>> spin counts), but there is no easy way to adapt these
>> for a target/runtime environment.
> Sure, more performance tuning knobs would be nice.
my problem was with getting the knobs right at runtime.
(i think this will need a solution to make tm practically
useful, there are settings that seem to be sensitive to
the properties of the underlying hw.. this also seems
to be a problem for glibc lock elision retry policies.)
>> i'm not sure why this has arch specific implementations
>> for some targets but not others. (syscall is not in the
>> implementation reserved namespace).
> Are there archs that support libitm but don't have a definition of this
i thought all targets were supported on linux
(the global lock based strategies should work)
i can prepare a sys_futex0 for arm and aarch64.
>> these are the issues i noticed that may matter if this
>> is going to be a supported compiler runtime.
> What do you mean by that precisely? For it to become non-experimental?
(since you were talking about libstdc++ changes to
complete the support for the TS).
More information about the Gcc-patches