On Wed, Sep 7, 2022 at 12:12 PM Marc Nieper-Wißkirchen < [email protected]> wrote:
> Yes, data structures whose locks are in an abandoned state are potentially >> inconsistent and if they are the best one can do with them is to have them >> GC'ed. But this does not necessarily mean that the global state of a >> program becomes inconsistent, does it? >> > It means that the future behavior of your program is completely unpredictable modulo special cases. I've probably referred to this before, but see < https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html> for explanations of why tampering with threads from outside the thread is unsafe in the general case. To quote the most important part: If any of the objects previously protected by these monitors were in an inconsistent state, other threads may now view these objects in an inconsistent state. Such objects are said to be *damaged*. When threads operate on damaged objects, arbitrary behavior can result. This behavior may be subtle and difficult to detect, or it may be pronounced. Unlike other unchecked exceptions, ThreadDeath kills threads silently; thus, the user has no warning that his program may be corrupted. The corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future. Using atomic operations, one can also program the data structures in a way > so that they can recover from an abandoned lock. > The data structure may recover, but the code that has already relied on the broken data structure cannot. If your sequence data structure has become circular when it was never expected to be, your thread that is trying to process it may go into an infinite loop processing what is otherwise garbage. When a time structure of hours-minutes-seconds was being updated from 00:00:59 to 00:01:00 and is terminated leaving 00:01:59, whatever thread depends on the time concludes that it has missed its deadline by a whole minute and panics the entire system to prevent further damage. And so on. Do you think it would make sense to add a primitive "critical-section" or > "atomic" that can be used to execute code during which `thread-terminate!` > is postponed? Such protected code must not call certain primitives like > mutex operations, etc. > Directly or indirectly, that is, and that is hard/impossible to determine in the general case. Posix signal handlers impose analogous restrictions, and what it comes down to is "just use the handler to set a flag and then poll that flag in the main part of the code". Again see the link above. Any similar approach just puts lipstick on the pig. My native-speaker alarms are going off, but I need to see the whole >> proposed revision. >> > > The consolidated changes are in my private repo. > >> I'll review the whole SRFI de novo when I can.
