Am Sa., 29. Okt. 2022 um 23:52 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sat, Oct 29, 2022 at 12:31 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
>> Thanks to SRFI 18's notion of abandoned mutexes, you can arrange it so
>> that data structures won't be in an undefined condition. This is, in
>> principle, no harder than arranging that data structures can be shared
>> between two threads.
>
>
>
> Per contra.  Consider a simple double-entry bookkeeping system in which an amount is atomically subtracted from one account A and added to another account B.  Suppose that we use a single global mutex to eliminate issues around deadlock.  Then if a thread is destroyed while holding the mutex, it is possible to tell that the account balances are wrong, but not *how* they are wrong: the amount may have been subtracted from A but not added to B or vice versa, or both, or neither.  It is unsatisfactory to simply give up in these circumstances.

You just have to add a state flag and two shadow cells A' and B'. The
state is initially cleared.  The thread locks the mutex, copies A to
A', and B to B', sets the state, "transfers" the amount from A to B,
clears the state, and unlocks the mutex.  The invariant is that
whenever the state is set, A' and B' hold the old values.  So if
another thread detects an abandoned mutex, it locks it. If the state
flag is set, the thread copies A' and B' into A and B, clears the
state flag, and unlocks the mutex. Otherwise, it just unlocks the
mutex.

A real-world system like a distributed database must also cope with the issues.

If exceptions coming from outside can be raised in the mutator thread,
you will also have to code similarly. You can have an exception
handler around your atomic transfer code, but the exception handler
would have to do the same as I sketched.  And the exception handler
itself could be interrupted at any time.

>
>> In the current semantic model of Scheme (and of SRFI 18 bar
>> extensions), exceptions are synchronously raised in the sense that an
>> exception is only raised during specific evaluations, and which
>> exceptions are raised is documented in the various specifications.
>> Concurrent programming is not impossible in this model.
>
>
> Not impossible, just incomplete in practical terms.

In multi-threaded application code, I have never used signal handlers
to send signals to other threads. The problem is that these signals
can be delivered at any time (e.g. during a money transfer) and not at
an application-specific safe point.  So all you can do is to have the
signal handler (which can't do much in POSIX anyway) set a flag and
let the thread code poll this flag whenever it has arrived at a safe
point.  But then you don't need the signal handler anymore; you can
just have the flag set by the signaling thread.

POSIX/C/C++'s (I don't know about Java) asynchronous signals are far
more limited than what the possibility of raising exceptions at any
time in Scheme would amount to.  And C and C++ are supposed to be
practical programming languages suitable for multi-threading
programming.  (But, of course, we want Scheme to be more practical, so
this is no argument for not adding "asynchronous exceptions").

>> So to implement what you have in mind, the semantic model would have
>> to be extended so that every evaluation step can, in principle, cause
>> an arbitrary exception to be raised.
>
>
> Of course the size of a step does not have to be allowed to be arbitrarily small.  With cooperative cancellation, cancellation happens just when the per-thread cancellation flag is polled.

Are you talking about the scheme evaluator's implementation or the
(high-level) Scheme program itself?

>> I would like to be able to kill a thread that loops forever.
>
>
> I would like it too, but the cost of allowing a thread to be killed at an arbitrary point is too high to pay.

Thread-exit! doesn't have to kill a thread "instantly" (whatever this
means), just eventually.  Only at synchronization points, the temporal
order can be observed (and has to be correct).

~~~~

Let me sketch the proposals that are floating around (and correct me
if I have misunderstood a thing).  Then we can refine them so that we
get the details right and so that there is no danger of talking past
each other:

(1) A procedure (thread-exit! THREAD).  This works like SRFI 18's
`thread-terminate!' except that it returns immediately.  The abnormal
termination of a thread happens asynchronously as long as the
observable sequence of events remains consistent. SRFI 18's concept of
abandoned mutexes is used to prevent critical data structures from
entering an undefined state.

(2) A procedure like "(thread-raise! THREAD CONDITION)".  This
procedure causes the evaluator of THREAD to raise a non-continuable
exception with condition object CONDITION at some
implementation-defined safe point (subject to the same sequential
constraints as in (1)).  This means that, in principle, any evaluation
step may proceed with running the code of the current exception
handler.

(3) A procedure like (thread-signal! THREAD SIGNAL [TIMEOUT]).  This
procedure causes the evaluator of THREAD to pause its current
evaluation and to invoke THREAD's *signal handler* (a new concept,
similar to an exception handler) in the dynamic environment where the
current evaluation is paused.  When the signal handler returns, its
results are delivered to the caller of `thread-signal!` and the paused
evaluation of THREAD is continued.  One needs an accompanying
procedure like `with-signal-handler'.

(4) A procedure like (thread-interrupt! THREAD THUNK [TIMEOUT]).  This
procedure causes the evaluator of THREAD to pause its current
evaluation.  It then invokes THUNK in the dynamic environment where
the current evaluation is paused.  When the THUNK returns, its results
are delivered to the caller of `thread-interrupt!' and the paused
evaluation of THREAD is continued.

(5) A procedure like (current-thread-exit!) that is like
"thread-exit!" but only for the current thread.