2

Reading about why is Thread.stop() deprecated,

Because it is inherently unsafe. Stopping a thread causes it to unlock all the monitors that it has locked. (The monitors are unlocked as the ThreadDeath exception propagates up the stack.) 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.

I have encountered inconsistent state phrase. I have tried to use google to know what it means. I have found only this answer, but it doesn't seem to concern my case.

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
VanechikSpace
  • 265
  • 2
  • 9
  • 7
    Thinks of a thread in a banking app. It locks the account to debit and the one to credit. It manages to deduct from the debit account, then gets killed before it can add the money to the other account. Now you effectively lost money. – Robert Jun 13 '22 at 16:06
  • (1) Do you understand what's meant by "locking" a "monitor"? (2) Do you understand the purpose of a monitor lock -slash- a `synchronized` block? (3) Do you understand why it could be a problem if a `synchronized` block suddenly exits after making some, but not all, of the changes it's supposed to make? – ruakh Dec 01 '22 at 04:46

2 Answers2

1

A thread could be killed at any time by having its stop() method called. So the consequence is that the thread has no warning that it is going to be killed. In particular, a thread could be in the middle of performing some critical operation when it is killed. If this occurred when a critical operation had not been completed then whatever data & resources it was using at the time it was killed, could be left in an inconsistent state. Such objects are said to be "damaged". The data corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future.

Ben
  • 395
  • 1
  • 5
  • 16
  • This is all true, but doesn't seem to answer the question, which is about what "inconsistent state" means. – ruakh Dec 01 '22 at 04:47
1

The dictionary says:

inconsistent

lacking consistency: such as

  • not compatible with another fact or claim

    "inconsistent statements"

In computer science, state is inconsistent if it contradicts itself. For instance, because information is stored in several forms, and the code updating the information has managed to update one form, but got killed before it could update the other.

For instance, consider this code:

synchronized void add(Listener l) {
    listeners[listenerCount++] = l;
}

If a thread is killed after incrementing listenerCount, but before writing the array element, the object is in an inconsistent state, because the listenerCount knows about more listeners than the array. And if some other code does:

synchronized notifyListeners() {
    for (int i = 0; i < listenerCount; i++) {
        listeners[i].changed();
    }
}

it can, surprisingly, fail with a NullPointerException.

Ordinarily, the synchronized modifier would have prevented another thread from accessing the object while it is being updated. But if the thread suddenly dies, if will leave the synchronized block before cleaning up the mess it made, which unlocks the monitor, and permits other threads to use the object, and possibly stumble over the mess the dieing thread left behind.

meriton
  • 68,356
  • 14
  • 108
  • 175