Martin,

on Wed, 24 May 2023 10:56:26 +0200 you (Martin Uecker
<ma.uecker_at_[hidden]>) wrote:

> Am Mittwoch, dem 24.05.2023 um 09:35 +0200 schrieb Jₑₙₛ Gustedt:
> > Hi,
> >
> > on Wed, 24 May 2023 08:05:21 +0200 you (Martin Uecker via Liaison
> > <liaison_at_[hidden]>) wrote:
> >
> > > Am Mittwoch, dem 24.05.2023 um 07:17 +0200 schrieb Martin Uecker:
> > >
> [...]
> > > ...
> > > [...]
> > > [...]
> > > [...]
> [...]
> [...]
> >
> > Hm, I don't think that this should be separated from the general
> > discussion of UB.
> >
> > > 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. 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.

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


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

Thanks
Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::