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:
Hi,
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
support.
...
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
example.
i see.
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).
xmalloc
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
allocation).
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.)
sys_futex0
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
one?
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?
yes, non-experimental
(since you were talking about libstdc++ changes to
complete the support for the TS).
