thread related questions

Thread view:

puzzlecracker - 01 Aug 2006 01:42 GMT

a.

let's say thread A calls wait or sleep during the execution, meanwhile
thread B calls ThreadA.interrupt();

does interrupt method blocks, waiting for A to finish wait/sleep and
then interrupting it? Does it asynchronouysly let jvm know to cancel
thread A upon the return, and those returns immediately?

b. does it make sense (is it allowed to pass runnable class with
synchronized method to Thread class or have one in subclass of Thread,
thereby letting start spawn the thread)to synchronize the run method.
If so, is it a good practice?

thanks

Reply to this Message

EJP - 01 Aug 2006 02:24 GMT

> does interrupt method blocks, waiting for A to finish wait/sleep and
> then interrupting it?

No, it interrupts it immediately.

> Does it asynchronouysly let jvm know to cancel
> thread A upon the return, and those returns immediately?

It returns immediately. I have no idea whether the operation is
synchronous or asynchronous, or whether this is even specified, but I
doubt that it matters.

> b. does it make sense (is it allowed to pass runnable class with
> synchronized method to Thread class or have one in subclass of Thread,
> thereby letting start spawn the thread)to synchronize the run method.
> If so, is it a good practice?

I don't understand this question.

Reply to this Message

Mark Space - 01 Aug 2006 05:39 GMT

>> does interrupt method blocks, waiting for A to finish wait/sleep and
>> then interrupting it?
[quoted text clipped - 7 lines]
> synchronous or asynchronous, or whether this is even specified, but I
> doubt that it matters.

Kinda a good point. I assume that interrupt() is basically a Unix
signal. That is, an interrupt is a little flag that gets set in the
process control block for that process, and then the kernel dispatches
appropriately.

This is pretty easy to envision if there's only one CPU. When the
kernel (or JVM) is setting the interrupt flag, all process are waiting
in some queue, and the kernel is the only thing executing. With
multiple CPUs, there's the issue that ThreadA may be under execution
when some other process tries to interrupt it.

What happens I think has to be architecture dependent. These are
software interrupts, not hardware interrupts, and unless there is some
way in hardware CPU-B can slap CPU-A and tell it to stop executing,
there's no way to deliver the interrupt immediately. I guess one has to
assume that the interrupt is asynchronous for both threads, and it's
only processed when the JVM actually gets around to it.

Reply to this Message

hiwa - 01 Aug 2006 06:02 GMT

puzzlecracker のメッセージ:

> a.
>
[quoted text clipped - 11 lines]
>
> thanks

If ThreadA was doing wait() or sleep(),
ThreadA.interrupt() would cause an
InterruptedExcepion thrown. Rest would
depend on what the exception handler did.
The interrupt() method itself always
returns immediately.

For your question b, I don't understand
what your are talking about.

Reply to this Message

jvsoft.org@gmail.com - 01 Aug 2006 10:32 GMT

See some thread tutorials
http://www.developerzone.biz/index.php?option=com_content&task=view&id=119&Itemid=36

Reply to this Message

puzzlecracker - 02 Aug 2006 07:55 GMT

> For your question b, I don't understand
> what your are talking about.

Is the following allowed and/make sense from design point of view?

Thread thread= new Thread ( new Runnable(){
public void synchronized run(){
// do something
} }
);

or effectively inhereit from the Thread class and provide
implementation for run as synchronize.

thanks

Reply to this Message

EJP - 02 Aug 2006 12:14 GMT

> Is the following allowed and/make sense from design point of view?

Yes. (new Thread(Runnable)).

> or effectively inhereit from the Thread class and provide
> implementation for run as synchronize.

Either will work. The API specifies all this, and yo ucan try it
yourself: why are you asking here?

Reply to this Message

thread related questions

Free Magazines