Am Mittwoch, dem 24.05.2023 um 11:24 +0200 schrieb Jₑₙₛ Gustedt:
> Martin,
> > >
> > >
> > > > Just some thoughts: The definition of data race is already tied
> > > > to a concrete definition of having conflicting accesses in two
> > > > two threads for a actual execution.
> > >
> > > And there are already at least two problems with that
> > >
> > > - It doesn't say at all what guarantees for side effects in
> > > unrelated (detached) threads we would be able to make. The current
> > > definition of UB has it that the whole execution goes down the
> > > drain.
> >
> > This is - in C - not the current definition of UB as it does not
> > follow from the definition we currently have in the standard.
> > But it is a common interpretation .
>
> I think it is the only reasonable interpretation.

Obviously I do not agree with this ;-)

> And de facto it is
> the interpretation that thread implementations use, they usually
> terminate the whole program executions and abort even threads that are
> detached.

If there is no synchronization, then the I/O in the detached
thread is not "happens-before" anything the other thread
does. If there is UB somewhere in the other thread then the
I/O is not guaranteed to happen even with the concrete
interpretation. So nothing changes there.

The question is whether we want to have stronger semantics
here. With a concrete interpretation this could be considered
(but would be another change), with the abstract interpretation
one can not do this. Once you say a program has no semantics,
there is simple nothing which can be done anymore.

But in general it seems difficult, as you can not even
guarantee that the detached thread made any progress
before the other thread encounters UB. There is also no
way to contain UB in one thread.

>
> > I think it is relatively clear what guarantees for observable behavior
> > (not side effects) we can make in other threads: Those which
> > happen-before the operation with UB are guaranteed to happen before.
> >
> > Or is there another problem you see here?
>
> The problem is that "happens before" only works with
> synchronization. So if detached threads run for hours without
> synchronizing between each other, there is no happens-before and you
> could not give any guarantee for such unrelated threads.

Yes, but I am not sure I understand what the problem is with this.

> They may well
> have observable side effects by writing into different log-files, for
> example. The thread that is erroneous because its behavior is
> undefined, could even do something equivalent to `fseek` and errase
> the written data or parts of it of the other thread.

Any guarantees for I/O are most meaningful if it is I/O
communicating with some external component or if it is
committed to an immutable log files etc.

> > > In general this problem space concerns all asynchronous execution:
> > > signal handlers, unsequenced expressions and threads.
> >
> > I will write down some arguments and I hope I can get
> > support from you and others. We have plenty of time now for
> > thinking about such things.
>
> We have some time, yes. And it is definitively worth to comb the
> standard for all these places and tidy them up.
>
> But one of the difficulties with UB is really completeness of the
> descriptions we have. We may look through the standards to see if the
> UB they describe fits into the model. It is more difficult to argue
> about implicit UB.

True, but especially for implicit UB saying the program has no
semantics at all seems rather radical.

Martin