Thread Execution

L

Linus

Im programming for a mobile phone (though this is not a J2ME question)
and basically I cant make a blocking call (such as opening a connection)
from an CommandListener because it causes deadlock.

So i created a new class that extends Thread that opens a connection, in
the constructor it takes the class that created it (i think its whats
called a call back) so that when it has created the connection it gives
back the data streams to the original class.

Should I continue execution from the call back method invoked by the
connection creator, or should I poll to see when the data streams are !=
null.

The latter seems pointless in situation where im trying to avoid
blocking. Im not quite sure how the garbage collector works but
basically after the call back has been made i dont need the connection
creater object any more so will it be destroyed? Or because thats the
thread thats running will it be kept alive, anyway im a bit confused
about how this all works so if someone could give me some pointers that
would be great.

HoboZilla
 
M

Matt Humphrey

Linus said:
Im programming for a mobile phone (though this is not a J2ME question) and
basically I cant make a blocking call (such as opening a connection) from
an CommandListener because it causes deadlock.

So i created a new class that extends Thread that opens a connection, in
the constructor it takes the class that created it (i think its whats
called a call back) so that when it has created the connection it gives
back the data streams to the original class.

Should I continue execution from the call back method invoked by the
connection creator, or should I poll to see when the data streams are !=
null.

Those pretty much are the two choices. The thread that actually creates the
connection must either call back to the original object (or some listener /
handler / lock object) or it must maintain state and be polled. Callback is
usually preferred to prevent delays and wasted time polling, but it requires
that the callback object be properly synchronized so that it can accept the
call from a 2nd thread. Polling still requires some synchronization, but
the caller can remain single-threaded.
The latter seems pointless in situation where im trying to avoid blocking.

That would only be true if your main thread spent all its time polling.
Usually it would intersperse polling with its regular work. Doing
"busy-idle" spin-polling is a bad idea all around. You can either embed
periodic polling into your other thread or go with the callback. GUIs like
Swing include an "invoke later" operation so the callback request occurs
properly threaded with the GUI.
Im not quite sure how the garbage collector works but basically after the
call back has been made i dont need the connection creater object any more
so will it be destroyed? Or because thats the thread thats running will it
be kept alive, anyway im a bit confused about how this all works so if
someone could give me some pointers that would be great.

Your new connection thread acts as an anchor to keep alive all the objects
reachable from the current thread state. After the connection thread makes
the callback, its work is done and the thread can exit. The objects
anchored by the thread will become eligible for garbage collection sometime
after that.

The platform you're on may also offer special techniques to help either with
the polling or callback operations.

Cheers,
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,767
Messages
2,569,572
Members
45,045
Latest member
DRCM

Latest Threads

Top