On Sat, Oct 29, 2022 at 12:31 PM Marc Nieper-Wißkirchen < [email protected]> 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. 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. 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. 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.
