Anupam Sinha

Ranch Hand
+ Follow
since Apr 13, 2003
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Anupam Sinha

This may not be exactly what the OP wanted. But still is a good read.

Chris Hurst wrote:

David Spades wrote: IMO, getSize() doesn;t need synchronizing. lets say another thread is in the middle of adding a new element when getSize is called, so the new element is not yet included in the count, which is valid since the adding is not yet finished, right?
this is my reasoning. is there any fault in this?

getSize needs to be synchronized. If one thread does all the adds and another was created at the same time as the first but never synchronizes on a common object with the mutating thread, getSize could in theory always return 0 for the second thread always/for ever i.e. empty collection regardless of any modifications by other threads because it never looks for change, the answer was zero the last time so surely its still zero as this thread hasn't modified it. By not not saying getSize is synchronized you are effectively allowing the reading thread to ignore all other threads changes if it decides its more efficient to do so i.e. your saying you don't care but you obviously do. In reality your getSize will most likely be observed to work (ish) but why take the risk ??

Can getSize always return 0 for the current code? Doesn't synchronize also provides a happens before guarantee?
What if someone accesses sequenceValue.getNextVal(); directly without the lock?
I think that the code is not thread safe.

This simple looking line

is not thread safe. Java only guarantees a 32 bit to be atomic (unless otherwise made atomic). So nextVal should be made volatile.

Apart from this I am not able to understand this program much.

I am unable to understand how this program (barring the above reason) will be thread safe (if it is made to compile).

getNextval is not synchronized so even acquiring a lock on sequenceValue shouldn't matter much.
Pasted below in the code for join method in Thread class.

It checks it the current thread is alive. If the thread is alive it then calls wait on the thread. In this case it seems that if t.join() was called it will be t that is made to wait. Whereas it should be the thread from which t.join() was called, should wait. Secondly what happens to the lock when any of the thread goes waiting?
I feel that the water is being used as a curtain to project the images. SO it's more like a lighting effect on fountain.
9 years ago
For all the units that were purchased before an year i.e. all the units you had bought before Jan 08 you don't owe any money. For the rest of the units you would be charged 10% of the profit. The 15% STCG tax is from this financial year.
9 years ago
It's your site and you decide what you want and it's my mind and I decide what's correct according to me. I still hold by my opinion and you hold onto yours.
[ June 12, 2008: Message edited by: Anupam Sinha ]
9 years ago
My main point was not why the thread was closed but the fact that it could had been done in a better fashion. I guess this thread is going nowhere. Again I feel in the be nice thing. Let's just try to be nice.
9 years ago

[UD]: His words were: The thread had gone on for three pages already, and no one on either side had learned anything. I think that sums it up nicely

It sure does. But it would had been great if these words were used on that thread as well.
[ June 11, 2008: Message edited by: Anupam Sinha ]
9 years ago
Why Paul you are you always in such a mood. I know it's your site. I just posted what I felt.

The thread could had been simply closed if it was felt it was going nowhere.

"In any event, at this point I am just so annoyed by this thread that I'm going to close it so I don't have to listen to the nonsense anymore"

This sentence makes me feel like that EFH didn't wanted to have this thread around because he didn't like it rather than it was not going anywhere, to which I said he could simply ignore it.

I have seen many closed threads in MD. In them it's generally "This thread is going nowhere and it is being closed". But in this case this was not the case.

Does this comes anywhere close to BEING NICE.

I guess you would not be persuaded with my point. Just trying.
9 years ago
According to me EFH was wrong in closing the thread. I know that this is a private forum but this also goes against the "Be Nice" thing. Secondly EFH could have chosen to simply ignore the thread rather than delete it. People who are so against MS are also a cause why other OSs don't spread. Rather than proving their point how to get things right they would simply close the discussion.
9 years ago
You can still stop someone else from patenting your stuff if you decide not to patent it. It is I guess called publishing your work.
10 years ago

Originally posted by Chandra Kota:
Hello All,

As per my understanding, once a thread completes its run() method, it moves to dead state. i.e it can not be thread of execution again. In trying to invoke start() method again on that reference, we will have an exception in place. But thread object itself is not nullified. The object is still on heap and has a valid reference.In fact, we can still invoke any other methods defined in our thread object except start(). Now since the object is having a reference, it is basically not eligible for GC. Correct me if I'm wrong. Thanks in advance.

You can catch them but it would not be the right thing to do. Basically errors are something which crops up due to an error in the underlying enviornment. Though even if you catch it, I guess it would be quite difficult to correct it. So I would suggest it's better left unhandled.
10 years ago