Race Conditions bei suspend/resume

[andre_w]

Hallo,

folgende Frage zu Folie 77 (Concurrency):

Suspend and resuming a thread (or stopping it all together)
(Deemed to be unsafe due to their potential to cause deadlock and race conditions.)

Dass es zu Deadlocks kommen kann, finde ich logisch, denn die Locks werden bei Aufruf von suspend ja nicht freigegeben.

Wie allerdings kann es hier zu einer Race Condition kommen? Dazu wäre es ja nötig, dass 2 Threads versuchen, auf dieselbe Resource zuzugreifen - durch Aufruf von Suspend würde das denke ich eher nicht passieren. Auch nach dem Resume sollte es keine Race Condition geben, da der Lock ja die ganze Zeit gehalten wurde.

Beste Grüße,
Andre

[eichberg]

Die Aussage in Hinblick auf "Race Condition" bezieht sich unter anderem auf folgende Aussage aus der JavaDoc:

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.

http://download.oracle.com/javase/1.5.0 ... ation.html