I am replacing synchorinized methods with blocks. I have one of the block like this:
As you see, the above code inside this block calls 2 methods, which are also accessed by many threads.
My doubts are : 1) Since the find() method is synchronized for any thread, should that be included inside the sync block (the top code, written inside the block)? 2) The find method does not use db directly, but is accessed by many Threads. Hence can this be a completely synchronized method than using a blocks inside (which I feel is not possible)? If writing a block is possible, should it be around the seek() called from find() ? 3) seek() is called from a sync block above (the top code, written inside the block). Since both the caller and called are been blocked with the same instance 'db' , does synced block in seek() becomes redundant? If so, can I remove that and make it a normal method. Please help me understand the above. Thanks in advance, Rajesh
The only place you can use or possibly need a sync block is in the lock and/or the unlock methods. You do not need them anywhere else. I would not include them anywhere else. Mark
About synchronizing again: In my sample code for the Data class a RandomAccessFile is used for directly for storage, and in almost every method seek() is called to position the file pointer. So in my understanding every method that deals with the file pointer has to be synchronized thus preventing other threads from repositioning the pointer. Am I wrong with this?
Where did you get an idea that you should rewrite the methods of the Data class? It's perfectly fine, -- stay away from it!
Eugene, I did'nt understand what you meant by rewriting. I am writing the functions of getting the recordCount, going to the end of file, writing the new record and updating the recordCount in one shot, inside a block. This is because, if one thread has placed a filepointer somewhere before adding a record. In the mean time , some other thread should not put the pointer somewhere else for its use. Please advise me if I am on the right track. Rajesh
I concur --- it does sound as if you are way off track. The only things you really have to do is remove deprecated API, add a criteriaFind method and perhaps implement lock() and unlock() (many don't do that in Data however). - Peter
I think work got messy because I wanted to replace the synchronized methods with blocks (for performance reasons). Are blocks not neccessary? Shall I continue to use the synchronized methods?
"(for performance reasones)" Actually the instructions state that you shouldn't make changes for performance reasons, and like Eugene and Peter added you shouldn't alter the Data class like that, it is unneccesary. Mark
Hi all, I'm still confused ... besides the question whether to modify Data and introduce blocks - what about the file pointer?? I still think it is necessary to synchronize all threads that modify the file pointer. And since Data holds exactly one file handle, isn't it ok to use the synchronized keyword on the Data methods ?
I still think it is necessary to synchronize all threads that modify the file pointer.
Perhaps your asignment is different, though I doubt that. In my assignment, all the methods of Data that use seek() are already synchronized. Threfore, if all threads use the same instance of Data, the methods are thread-safe. Maybe you made the method seek() public and you call it explicitely from your client code (I've seen this in someone's design), hence your question. If so, I would strongly encourage you to reconsider. Eugene.
In my assignment, all the methods of Data that use seek() are already synchronized. Threfore, if all threads use the same instance of Data, the methods are thread-safe.
Oh, seems that I was misled. Yes I've got the assignment samples with the right methods synchronized. I just got somehow unsure about this while following the discussion. Thank you very much for making this clear. - Ralf
Post by:autobot
I'm not dead! I feel happy! I'd like to go for a walk! I'll even read a tiny ad:
a bit of art, as a gift, the permaculture playing cards