myThread.isAlive() v.s. WeakReference ? URLyBird 1.2.2 using Socket

[Anusorn Swasdee]

In lock mechanism, if I want to check weather the Object that
lock the record is still alive, what is the better choice -- .isAlive()
or WeakReference?


I've test something with WeakReference

import java.lang.ref.WeakReference;
 
public class TestWeakReference {

/**
 * Method main
 *
 *
 * @param args
 *
 */
public static void main(String[] args) {
Thread myThread = new Thread(new MyRunnable());
WeakReference wr = new WeakReference(myThread);
myThread.start();
for(int i=0;i<10;i++) {
System.out.print("Main : Weak Ref ");
System.out.println(wr);
}
}
}
 
class MyRunnable implements Runnable {
public void run() {
for(int i=0;i<10;i++) {
System.out.println("MyRunnable");
}
}
}

And the Result is..

Main : Weak Ref java.lang.ref.WeakReference@18e3e60
Main : Weak Ref MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
java.lang.ref.WeakReference@18e3e60
Main : Weak Ref java.lang.ref.WeakReference@18e3e60
Main : Weak Ref java.lang.ref.WeakReference@18e3e60
Main : Weak Ref java.lang.ref.WeakReference@18e3e60
Main : Weak Ref java.lang.ref.WeakReference@18e3e60
Main : Weak Ref java.lang.ref.WeakReference@18e3e60
Main : Weak Ref java.lang.ref.WeakReference@18e3e60
Main : Weak Ref java.lang.ref.WeakReference@18e3e60
Main : Weak Ref java.lang.ref.WeakReference@18e3e60
Press any key to continue...

It disappointed me. The WeakReference Still be there.
Not equal null as it should be.
Which means when I use

if(myWeakReference==null)
    //unlock the record that has been locked.

It may be no guaranteed that I can detect the lost or disconnect client!


And when I try myThread.isAlive()

public class TestThreadIsAlive {

/**
 * Method main
 *
 *
 * @param args
 *
 */
public static void main(String[] args) {
Thread myThread = new Thread(new MyRunnable());
myThread.start();
for(int i=0;i<10;i++) {
System.out.print("Main : MyThread Alive? ");
System.out.println(myThread.isAlive());
}
}
}
 
class MyRunnable implements Runnable {
public void run() {
for(int i=0;i<10;i++) {
System.out.println("MyRunnable");
}
}
}

The result is ...

Main : MyThread Alive? true
Main : MyThread Alive? true
Main : MyThread Alive? true
Main : MyThread Alive? MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
false
Main : MyThread Alive? false
Main : MyThread Alive? false
Main : MyThread Alive? false
Main : MyThread Alive? false
Main : MyThread Alive? false
Main : MyThread Alive? false
Press any key to continue...

Is my understanding is true?

Then, why discussion in this forum choose to use WeakReference?


Waiting for your reply and
Thanks in advance
Anusorn
[ February 15, 2005: Message edited by: Andrew Monkhouse ]

[Andrew Monkhouse]

Hi Anusorn,

I have put your code between [code] and [/code] UBB tags. Doing so helps preserve indentation, making your code easier to read, which improves your chances of getting a reply.

Two problems with the code you presented:

You were not giving the JVM time to run the garbage collector (and/or not explicitly running the garbage collector)

You were looking at whether the WeakReference object existed rather than it's referent

.

Take a look at the following code:

import java.lang.ref.WeakReference;
 
public class TestWeakReference {
public static void main(String[] args) throws InterruptedException {
WeakReference wr = new WeakReference(new MyRunnable());
 
((Thread) wr.get()).start();
((Thread) wr.get()).join();
 
for(int i=0;i<10;i++) {
System.gc();
Thread.sleep(5000);
System.out.print("Main : Weak Ref ");
System.out.println(wr.get());
}
}
}
class MyRunnable extends Thread {
public void run() {
for(int i=0;i<10;i++) {
System.out.println("MyRunnable");
}
}
 
public void finalize() {
System.out.println("MyRunnable finalize");
}
}

Which, when run, could give the following output (remember the call to gc() is only a request):

C:\Temp>java TestWeakReference
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
MyRunnable
Main : Weak Ref Thread[Thread-0,5,]
MyRunnable finalize
Main : Weak Ref null
Main : Weak Ref null
Main : Weak Ref null
Main : Weak Ref null
Main : Weak Ref null
Main : Weak Ref null
Main : Weak Ref null
Main : Weak Ref null
Main : Weak Ref null

Regards, Andrew

[Anusorn Swasdee]

Thank you very much. ^ ^

Your example does help much. If you don't post, I may still go wrong
direction.

Sorry for the bad code layout, next time I will type it in code tag.

Thanks for your reply.
from Anusorn.

[Anusorn Swasdee]

I've run your code and have 2 different results.

...
MyRunnable
MyRunnable
MyRunnable finalize
Main : Weak Ref null
Main : Weak Ref null
...

and

...
MyRunnable
MyRunnable
Main : Weak Ref Thread[Thread-0,5,]
MyRunnable finalize
Main : Weak Ref null
Main : Weak Ref null
...

Interesting.

Do these results mean that the to-be-joined object
of the running thread may or may not go to dead state
before doing it's finalize() method?

Or is it dead already before doing the finalize() method, and
the wait-to-join thread can decide to change to running state whether
before or after the finalize() method of the dead thread
be executed?

Very detailed example!!!
Thanks. :-)

[Andrew Monkhouse]

Hi Anusorn,

Finalize won't be called until after the thread has finished running.

My purpose in showing when finalize was run, was to show the correlation between the object being garbage collected and the weak reference referent being cleared.

Regards, Andrew

[joe lin]

hi all,
I think my next question is related to the above content.
my question is:
suppose there is a thread which stands for a client and that thread hold a lock on one record(that record exist in the remote server side),but at this
moment,the client crash!so i want to know,after that client crashed,is that thread which stands for that crashed client still alive?Does that thread still hold the record lock? can use the WeakReference object solve this problem?
thank you all in advance!

[Jamal Freeman]

suppose there is a thread which stands for a client and that thread hold a lock on one record(that record exist in the remote server side),but at this
moment,the client crash!so i want to know,after that client crashed,is that thread which stands for that crashed client still alive?Does that thread still hold the record lock? can use the WeakReference object solve this problem?
thank you all in advance!

my SCJD implementation-in-progress is socket-based, so when a client dies, its corresponding server-side thread will catch a socketexception and do the necessary cleanup (releasing lock held, etc) just before terminating.

[Frank Hardy]

Hi Anusorn,

I've exactly the same assignment but I used an approach which is completely different from yours to deal with "hanging locks".
In my approach each lock has an expiration time which can be configured. My locks are represented by lock-objects and are managed by a manager instance. Each lock-object gets a timestamp (current system time) when it is created. Each time the lock manager is accessed it will check the timestamp against the current system time. The difference to the timestamp is calculated and when the expiration time limit is exceeded the lock is no longer valid and will be removed or substituded by another one.

I think this is a very simple and acceptable solution for this problem.

What do you(others) think?

Greetz,

Franky.

[Andrew Monkhouse]

Hi Franky,

In my opinion, since the instructions for the lock method do not mention anything about a timeout, I am not sure that you are implementing the functionality that Sun would like you to implement.

Regards, Andrew

[Frank Hardy]

Hi Andrew,

hmmmm...yes...you're d#mn right.
Aaah! How could I miss that? I'm thinking too much over that.
Thanks a lot for your hint.

But the "hanging lock" problem is noteworthly.
I've kicked my timer solution. Now I've substituted it by checking the owner thread-object of a lock if it is still alive (fortunatly it was not much effort). Locks that are owned by dead threads will be now removed automatically. This doesn't break the interface contract. As long a thread is alive it will hold its record locks. In the case a Programer (me) has forgotten to unlock the locked records or the thread is killed or dies without unlocking it record locks, the locks will be removed when at least another thread wants to lock the corresponding records.

Do you(all) think this is that a better solution?

Greetz,

Franky.

[Andrew Monkhouse]

Hi Franky,

This could work if you are using sockets (but then again, if you are using sockets, you could use the exception you get on disconnection as a trigger to clean up orphaned locks).

However if you are using RMI this will not work. Since this topic is talking about using sockets, I will not bore you with the details, however if you are using RMI, you might want to look at the topic "Using Thread ID for lock owner not safe?"

Regards, Andrew

[Frank Hardy]

Hi Andrew,

okay I see. RMI is typically using thread-pooling. And therfore I cannot be sure that the same thread which locked a record does unlock it. Furthermore, the threads in a pool won't die. isAlive() doesn't work at all.
I think I have to redesign.

Never mind, design is fun...

Thanks a huge lot again for your hint.

Regards,

Franky.