State of support for the ISO C++ Transactional Memory TS and remanining work

[Szabolcs Nagy]

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).