• Post Reply Bookmark Topic Watch Topic
  • New Topic

Shoud I get a null?  RSS feed

 
bujin wang
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why don't I get null object for this class?

 
Timmy Marks
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why don't I get null object for this class?

Can you explain what exactly you mean? When I read the code, what I expect to happen is this:
there will be many lines saying
Created object, api = null
and many saying
Created object, api = TimeConsumingObject@some memory adress
there will also be lines saying
Done released api = null in Thread: Thread some number
and others saying
Done released api = TimeConsumingObject@some memory adress
But I don't know what you are expecting to happen.
 
bujin wang
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I am expecting is from this line:
System.out.println("getObject = " + ObjectCreation.getObject() + " in thread: " + Thread.currentThread().getName());
Some lines say:
getObject = null in thread: Thread-???
....
Some lines say:
getObject = object@address in thread: thread-???
However I only got the latter case, not even one instance of the first one.

Can you explain why?
Burt
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ummm... your code checks to see if api is null, and if it is, it creates a new TimeConsumingObject, and returns that.

So, why would you expect this code to ever return a null? Sure, api will be null when you first encounter it, but then you create a new TimeConsumingObject() before you return. So it won't be null by the time you return. Meanwhile, other threads are also doing getObject(), and while the first TimeConsumingObject has not yet been created those threads will also find api == null. So they will also create new TimeConsumingObjects of their own, rather than simply waiting for the first thread to finish creating one. Which is quite wasteful, but there's no reason to expect that any thread should return a null from getObject(). The method is specifically written to make sure that it doesn't return null.
Normally when doing this type of thing, which is known as lazy instantiation, you'd want the getObject() code to be synchronized so that one one thread starts creating a TimeConsumingObject, the other threads will not exectue getObject() until after the first thread has finished. That way all subsequent threads will see that api != null, and they will not waste time creating new TimeConsumingObjects.

Does that help?
[ January 10, 2004: Message edited by: Jim Yingst ]
 
bujin wang
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think I understand that the getApi should be synchronized. Did you notice that there is a release() method which was also randomly release the api field randomly by other threads? If we commented the code you mentioned in your reply but to use the code block above it. We don't get any null case as well.
Burt
 
bujin wang
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, to be clearer, I think the question lies to this point:

How much time needed to do the ? Does it cost no time such that there is no way for other threads to do the call? If there is a time window for the assigning, then I should get some null cases.
Any idea?
Bujin
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does it cost no time
It costs a small but nonzero amount of time. Since this time is very short compared to the time spent in the TimeConsumingObject constructor, there is a very small chance that another thread will manage to execute api = null in between "api = theApi" and "return api". Furthermore some compiler or JVM optimizations may ensure that this never happens on some platforms. Which means that most of the time you'll have a hard time observing this particular bug - but if you've got a high-volume system, you may occasionally observe it. This type of bug is very difficult to track down, which is why it usually pays to set up synchronization correctly in the first place.
[ January 12, 2004: Message edited by: Jim Yingst ]
 
bujin wang
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am kind of believing what you said. Can you give me some references about this part? Non-zero
Thanks
Burt
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!