Kevin Simonson wrote:Of necessity variable {threadSuspended} is a member of my class that extends {Thread}. How do I access it in static method {terminaExecucao()}?
Static methods can access instances of objects, so your method could call a getter on your subclass of Thread and query the value of threadSuspended that way (likewise, a setter can alter threadSuspended for you). However, I strongly suspect this isn't going to solve your real problem, whatever it is. Typically, just following a rote approach to changing code isn't going to adapt real programs into the working, refactored versions you want them to be. Multi-threaded code is subtle stuff, where you really need to know what you're doing to be sure it's going to work.
You're doing the right thing by avoiding
Thread.suspend and
Thread.resume. Those are so dangerous that calling them "deprecated" seems somewhat too gentle, to me. Likewise,
Object.notify and
Object.wait, while still considered valid methods, are best left to legacy code, and not used directly anymore. Here's advice from a smarter head:
In Effective Java, 2d ed, Joshua Bloch wrote:In summary, using wait and notify directly is like programming in "concurrency assembly language," as compared to the higher-level language provided by java.util.concurrrent. There is seldom, if ever, a reason to use wait and notify in new code. (emphasis in original)
I do a lot of multi-threaded coding, and never need
Object.wait nor
Object.notify. I tend to use one of the implementations of the BlockingQueue interface, a Semaphore, and a few other members of
java.util.concurrent. I'd suggest you look at those classes and see if maybe they can simplify what you're doing. Feel free to post back here if you need help.