aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Is this sync right? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Is this sync right?" Watch "Is this sync right?" New topic
Author

Is this sync right?

Rajesh So
Ranch Hand

Joined: Oct 08, 2002
Posts: 141
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
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

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


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Ralf Riedel
Greenhorn

Joined: Dec 30, 2002
Posts: 5
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?
Rajesh So
Ranch Hand

Joined: Oct 08, 2002
Posts: 141
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
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

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.
Rajesh So
Ranch Hand

Joined: Oct 08, 2002
Posts: 141
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
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
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
Rajesh So
Ranch Hand

Joined: Oct 08, 2002
Posts: 141
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?
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

"(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
Rajesh So
Ranch Hand

Joined: Oct 08, 2002
Posts: 141
Thank you Eugene, Peter and Mark. It saved me from a lot of complications.
Ralf Riedel
Greenhorn

Joined: Dec 30, 2002
Posts: 5
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 ?
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

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.
Ralf Riedel
Greenhorn

Joined: Dec 30, 2002
Posts: 5
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 agree. Here's the link: http://aspose.com/file-tools
 
subject: Is this sync right?