Forums Register Login

Is this sync right?

+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
Thats exactly the problem, I had. But Mark's design seems to be very high and advanced.
I have coupled the seek and any operation on db into a block.

And writeRecord() again has sync block around the db usages.
See if this is right.
Rajesh
+Pie Number of slices to send: Send
 


I have coupled the seek and any operation on db into a block.


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.
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
"(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
+Pie Number of slices to send: Send
Thank you Eugene, Peter and Mark. It saved me from a lot of complications.
+Pie Number of slices to send: Send
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 ?
+Pie Number of slices to send: Send
 


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.
+Pie Number of slices to send: Send
 

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
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
https://gardener-gift.com


reply
reply
This thread has been viewed 912 times.
Similar Threads
NX: RandomAccessFile / Singleton DataSchema
Database Thread Safety, pls review
Synchronization/locking question on persistDVD in Andrew's book
B&S, Q: good synchronization?
Design suggestions request
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 18:49:50.