• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Synchronized Methods/Blocks

 
Imed Ahras
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys:
Any Help with This:
most people have changed the signature of lock/unlock methods to become Synchronized Methods;
public void synchronized lock(int record)
But, this does not guarantee that the operation of checking the lockManager and setting the lock is atomic,
Since, since this synchronizes only access to this data obejct not the shared LockManger(hashMap or Collection), which can be accessed by another thread while this thread is executing the lock method.
------
Please in case i am wrong or misunderstand this synchronization business, just tell me how
-----
Thanx.
[ December 25, 2002: Message edited by: Imed Ahras ]
[ December 25, 2002: Message edited by: Imed Ahras ]
 
John Lee
Ranch Hand
Posts: 2545
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi:
In my program, the signature is:
void lock(int record)
Public is not necessay;
You can also get around Synchronized;
I heard a lot of people changed the signature, anyway, that is how I did it.
 
Jawad Kakar
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Method signature is the return type and the parameter list, adding synchronize does not change method signature.
Jawad
 
John Lee
Ranch Hand
Posts: 2545
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think Sun did not mention the term signature in its requirement. What Sun did is just showing a example of how lock() should look like?
void lock(int)
That leaves people wondering whether Sun require lock() in the same form. From reading posts on Javaranch, it looks like many alter it.
I keep the form, just for the sake of keeping it. Because I think it won't hurt.
 
Imed Ahras
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanx Guys :
But i am still a bit confused, is it alright to use this:
public void lock(int rec){
syncronized(lockManager){
............
}
}
which will synchronize the shared lock manager
or is it better to alter and use:
public void synchronized lock(int rec){
..............
}
which is going to synchronize the data object, but this does not mean to synchronize the shared resource(LockManager)
----------------
 
John Lee
Ranch Hand
Posts: 2545
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I used:
void lock(int rec){
syncronized(this){
............
}
}
 
Imed Ahras
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Don,
But to sychrnchronize on (this), it is the same as using a synchronizing the method;
Also;
suppose client A gets Da Data Object.
client B gets Db Data Object.
then while A is exeucting lock on Da Object,
also B can execute lock on Db object on the same time.
means they can modify the shared lock colloction(hastable or whatever suitable) at the same time.
cause using (this) in Your synchronization to my knowledge that :
if client A is executing Da Lock than B can not execute Da at that instance, however B has a different object (Db).
--------
Thanx
 
Jawad Kakar
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is better to synchronized on the method, easier to read and debug, then to synchroized on block.
Jawad
 
John Lee
Ranch Hand
Posts: 2545
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Imed Ahras:
Hi Don,
But to sychrnchronize on (this), it is the same as using a synchronizing the method;

Yes, it is exactly the same. I learn ths from scjp.
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Imed,
If your shared resource A is acceessed only through the synchronized methods of resource B, then only one thread at a time can access resource A. It's not very obvious, and that's probably why you are confused. For example:

In the code above, your shared resource is the lock collection, and although the code doesn't synchronize on that object explicitely, it is thread safe, because the only way to access it is through a synchronized method of the YourLockManager object.
Similarily, if your Data object is shared by multiple clients, and the lock/unlock methods of Data are synchronized, it is safe to NOT synchronize on the lock collection inside those methods, because only one thread at a time can access them anyway.
Since people choose different designs, it is meaninless to ask "Are your lock/unlock methods synchronized?", but here is a sample implementation:
-- The lock/unlock methods of shared Data are NOT synchronized
-- The lock/unlock methods of Data call the corresponding methods of LockManager, the methods of LockManager are synchronized.
-- LockManager uses a collection, which is a simple HashMap that doesn't need to be a synchronized collection, and you never need to synchronize on that collection explicitely.
You might be tempted to over-synchronize, -- but this is dangerous as it gives a potential for deadlock conditions. Just think your design and the use cases through.
Hope this is clear,
Eugene.
[ December 26, 2002: Message edited by: Eugene Kononov ]
 
Imed Ahras
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanx For Your post;
i got your point clearly, which is to wrap the collection with an object , and then define synchronized lock/unlock methods for this object:
-----
but in the Data class, lock methods and lock unlock methods should look like:these:

Every thing will be dealt with in the LockManager class where, No way two threads will overlap executing the lock methods or unlock
---------
Thanx
[ December 26, 2002: Message edited by: Imed Ahras ]
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

static LockManager myLockManager....
Every thing will be dealt with in the LockManager class where, No way two threads will overlap executing the lock methods or unlock.

Yeah, you got it. One more thing, -- don't use static lock manager instance, -- Peter den Haan gets very upset when he sees it
Eugene.
[ December 26, 2002: Message edited by: Eugene Kononov ]
 
Imed Ahras
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i think ; i need a static lockManager cause my design is :
one server, that creates Data Connection to each client,
And this Data Connection has to keep its locks in a place where others can see it, so better to make a static LockManager to be shared by all data connection objects,
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

And this Data Connection has to keep its locks in a place where others can see it, so better to make a static LockManager to be shared by all data connection objects

This is not good, -- what happens when another table is added to database (something like customers.db)? Your lock manager (and everything else) is now in the water.
Consider this instead:
100 remote clients operating with 5 database tables (files) translates into 1 connection factory bound to registry, 100 remote objects representing connections, 5 instances of Data, and 5 instances of lock manager. This multi-table design is fairly easy to implement, and I think this is what is expected, given the requirements for reusability.
Eugene.
[ December 26, 2002: Message edited by: Eugene Kononov ]
 
Imed Ahras
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanx Eugen

100 remote clients operating with 5 database tables (files) translates into 1 connection factory bound to registry, 100 remote objects representing connections, 5 instances of Data, and 5 instances of lock manager. This multi-table design is fairly easy to implement, and I think this is what is expected, given the requirements for reusability.

i think i got it
For Every Table , there will be a Data Object that has an instance Variable LockManager, cause if another Data Object created with different file name, The shared LockManager will be messed up.
Every client wants to connect we give a reference a of that data object, instead of creating a new data Object.
But For The multi-table design, a client can access all the data instances or not, or he will be given only one reference to the data object.
(not sure but i think, to all the data tables)

Thanx Again.
[ December 26, 2002: Message edited by: Imed Ahras ]
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

For Every Table , there will be a Data Object that has an instance Variable LockManager, cause if another Data Object created with different file name, The shared LockManager will be messed up.

Yes, and better yet, your remote object should have an instance of Data and an instance of a lock manager.
Eugene.
 
Imed Ahras
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Eugene
suppose i have got only one table;
means only one data object to be used by all clients;
Don't You think it is gonna slow the performance, cause every method in the Data class is synchronized;
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

means only one data object to be used by all clients;
Don't You think it is gonna slow the performance, cause every method in the Data class is synchronized;

Well, it's been postulated that optimization is the root of all evil. Sun reiterates this in your requirements by saying something that you should read as "clarity is a primary consideration, performance is secondary". So, don't worry about clients using the same instance of Data, you will do just fine. We are talking about milliseconds here, there is not much to optimize.
Eugene.
[ December 27, 2002: Message edited by: Eugene Kononov ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic